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Preliminary Program Symposium on Experiences 
with Distributed and Multiprocessor Systems (SEDMS III) 
Sponsored by the USENIX Association and The Software 
Engineering Research Center in cooperation with ACM and IEEE-CS 

Newport Beach, CA, March 26-27, 1992 


Goal 

The goal of this Symposium is to bring to¬ 
gether individuals who have built, are building, or 
will soon build distributed and multiprocessor sys¬ 
tems, especially operating systems. SEDMS III 
will feature refereed presentations on aspects of 
building, testing, debugging, and using these sys¬ 
tems. SEDMS III will provide a forum for indi¬ 
viduals to exchange information on their experi¬ 
ences, both good and bad, including experiences 
with coding aids, languages, distributed debug¬ 
ging tools, prototyping, reuse of existing software, 
performance analysis, and lessons learned from 
use the of such systems. 

Wednesday, March 25 

7:00 pm to 9:00 pm Registration 

7:00 pm to 9:00 pm Self-hosted reception 

Thursday, March 26 
8:40 am Opening Remarks 

George Leach, ATT Paradyne, General Chair 
Gene Spafford, SERC, Purdue, Program Chair 

9:00 am Keynote Presentation: System Support for 
High Performance Multiprocessing 

Professor Edward Lazowska, Computer Sci¬ 
ence and Engineering, University of Wash¬ 
ington 

10:30 am Parallelism 

Lessons from Implementing Active Objects on a 
Parallel Machine 

R. Capobianchi, R. Guerraoui, A. Lanusse, 
and P. Roux, CE Saclay DEIN/SIR, France 
Issues in Run-Time Support for Tightly-Coupled 
Parallel Processing 

D. G. Feitelson, Y. Ben-Aher, M. Ben Ezra, 
I. Exman, L. Picherski, L. Rudolph and D. 
Zernik, Department of Computer Science, 
The Hebrew University of Jerusalem 


Experiences Implementing the Minitabs System 
on a MasPar MP-1 

D. Y. Hollinden, D. A. Hensgen and P. A. 
Wilsey, Department of Electrical and Com¬ 
puter Engineering, University of Cincinnati 

1:30 pm Synchronization 

Experiences with Optimistic Synchronization for 
Distributed Operating Systems 
P. L. Reiher Jet Propulsion Laboratory, 
California Institute of Technology 

Experiences from Multithreading System V Re¬ 
lease 4 

J. Kent Peacock, S. Saxena, D. Thomas and 
F. Yang Intel Multiprocessor Consortium 

Dynamic Synchronization of Real-Time Threads 
for Multiprocessor Systems 

H. Zhou, K. Schwan and A. Gheith College 
of Computing, Georgia Institute of Technol¬ 
ogy; IBM, Austin, TX 

3:45 pm Distributed Shared Memory I 

Application Specific Coherence Control for High 
Performance Distributed Shared Memory 
R. Ananthanarayanan, M. Ahamad and R. J. 
LeBlanc College of Computing, Georgia In¬ 
stitute of Technology 

A Distributed Consistency Server for the CHO¬ 
RUS System 

F. Armand and M. Ines Ortega Chorus Sys- 
temes, France 

Design Considerations for Shared Memory Mul¬ 
tiprocessor Message Systems 

N. Islam and R. H. Campbell Department of 
Computer Science, University of Illinois at 
Urbana-Champaign 

5:30 pm Work-in-Progress Session 
Moderator: Mike O’Dell Bellcore, Morristown NJ 
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8:00 pm on 

Optional discussions, panels, BOFs, etc. 

Friday, March 27 

8:45 am Planning for SEDMS IV 
D. Cohn and others 

9:00 am Expanding the Domain 

Experiences of Handling Multimedia in Distrib¬ 
uted Open Systems 

N. Davies, G. Coulson , N. Williams and G. 

S . Blair Distributed Multimedia Research 
Group, Department of Computing, Lan¬ 
caster University, U.K. 

A Universal Distributed Programming Paradigm 
for Multiple Operating Systems 
D. L. Cohn, M. R. Casey, P. M. Greenawalt 
and J. E. Saldanha Department of Computer 
Science and Engineering, University of Notre 
Dame 

10:30 am Lessons Learned 

Experience in Parallel Performance Measure¬ 
ment: The Speedup Bias 
F. Wieland, P. Reiher and D. Jefferson Jet 
Propulsion Laboratory, California Institute 
of Technology, University of California, Los 
Angeles, CA 

Supporting User-Level Exception Handling on a 
Multiprocessor Micro-Kernel: Experiences 
with Platinum 

R. J. Fowler and L. I. Kontothanassis Com¬ 
puter Science Department, The University of 
Rochester 

Experiences with Accommodating Heterogeneity 
in a Large Scale Telecommunications Infra¬ 
structure 

J. R. Nicol, C. Thomas Wilkes, R. D. Ed- 
miston and J. C. Fitzgerald GTE Laborato¬ 
ries, Inc., Waltham, MA 

1:30 pm Distributed Shared Memory II 

Efficient Order-Dependent Communication in a 
Distributed Virtual Memory Environment 
J. N. Griffioen Computer Science Depart¬ 
ment, University of Kentucky 

Implementing DVSM on the TOPSY Multicom¬ 
puter 

T. Stiemerlingy T. Wilkinson and A. Sauls- 
bury City University, London, U.K. 

Integrating Consistency Control and Distributed 
Shared Memory: The Travails of an Implemen¬ 
tation 


R. C. Chen and P. Dasgupta Siemens Nixdorf 
Information Systems, Cambridge, MA, De¬ 
partment of Computer Science and Engineer¬ 
ing, Arizona State University 

3:30 pm Language Support 
Transparent Fault-Tolerance in Parallel Orca Pro¬ 
grams 

M. Frans Kaashoeky R. Michiels, H. Bal and 
A. Tanenbaum Faculteit der Wiskunde en 
Informatica, Vrije Universiteit, Amsterdam, 
Netherlands 

Class Libraries as an Alternative to Language 
Extensions for Distributed Programming 
T. G. Dennehy ATT Bell Laboratories, 
Whippany, NJ 

4:30 pm Adjourn - We’re going to Disneyland! 

Program Committee 

William Bain, Intel Corp. 

John Barr, Motorola, Inc. 

Bharat Bhargava, Department of Computer Sci¬ 
ences, Purdue University 
David L. Cohn, Department of Computer Science 
and Engineering, Univ. of Notre Dame 
Dan Duchamp, Computer Science Dept, Colum¬ 
bia University 

Andrzej Goscinski, University of New South 
Wales 

Howard Katseff, ATT Bell Labs 
Yousef Khalidi, Sun Microsystems 
Susan LoVerso, Thinking Machines Corp . 

Elie Milgrom, Louvain University, Belgium 
John R. Nicol, GTE Laboratories 
Mike O’Dell, Bellcore 
Marc Pucci, Bellcore 

Karsten Schwan, College of Computing, Georgia 
Institute of Technology 

Satish Tripathi, Department of Computer Science, 
University of Maryland 
C. Thomas Wilkes, GTE Laboratories 

George Leach, ATT Paradyne Corp. (General 
Chair) 

Gene Spafford, Software Engineering Research 
Center/Department of Computer Sciences, Pur¬ 
due University (Program Chair) 

Registration Information 

Registration information may be obtained by 
contacting the usenix Association Conference 
Office Phone: (714)588-8649 Fax: (714)588- 
9706), or via e-mail: judy@usenix.org 
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Call for Papers: USENIX Systems Administration 
Conference (LISA VI) 

Long Beach, CA October 19-23, 1992 


The annual LISA conference provides a fo¬ 
rum in which system administrators from a variety 
of sites can meet to share new ideas and experi¬ 
ences. A growing success for the past five years, 
LISA is the only conference which focuses spe¬ 
cifically on the needs of system administrators. In 
previous years, LISA has targeted large installa¬ 
tions. However, this year we are extending the 
scope of LISA to include system administrators 
from all UNIX sites. 

The Sixth usenix System Administration 
Conference (LISA VI) will be held in Long 
Beach, CA on October 19-23,1992. A dual-track 
tutorial program will be offered during the first 
two days of the conference, followed by a three- 
day technical conference. The tutorial program 
will address issues in introductory and advanced 
system administration. 

The program committee will be reviewing 
papers submitted on subjects including (but not 
limited to): 

Tools for Real-Time System Troubleshooting 
Remote/Off-site System Administration 
Tricks in User Education 
Graphical User Interfaces for System Ad¬ 
ministration 

Distributed System Administration 
Experiences Using Third-party Administra¬ 
tion Software 

Network Growth and Performance Manage¬ 
ment 

How to Grow Your Own Junior System Ad¬ 
ministrators 
Network Management 
Wireless LANs 
System Security Monitoring 
Evaluating Performance of High-End Work¬ 
stations and Servers 
Keys to Successful, Painless Upgrades 
Object Management Systems for System Ad¬ 
ministration 

Standardization of System Administration 
Heterogeneous System Administration 
System Archiving and Backups 


We are especially interested in papers which 
provide freely available or fully described solu¬ 
tions to existing problems. We are also looking for 
papers which, in some way, advance the state of 
the art. 

The committee requires that an extended ab¬ 
stract be submitted for the paper selection process 
(full-papers are not acceptable for this stage; if 
you send a full paper, you must also include an 
extended abstract for evaluation). Your extended 
abstract should consist of a traditional abstract 
which summarizes the content/ideas of the entire 
paper, followed by a skeletal outline of the full 
paper. Final papers should be from 5 to 20 pages 
in length, including diagrams and figures. Papers 
should include a brief description of the site, an 
outline of the problem and issues, and a descrip¬ 
tion of the solution. We require electronic form 
of the extended abstract; we require both hard¬ 
copy and electronic (nroff/troff or ASCII) form of 
the final paper. 

Conference proceedings will be distributed to 
all the attendees and also will be available after 
the conference from the usenix Association. 

In addition to tutorials and regular technical 
sessions, a handful of other events will be in¬ 
cluded as part of the program. For example, the 
program may include special panels, work-in- 
progress reports, birds-of-a-feather (BOF) ses¬ 
sions, and invited talks. The program committee 
invites you to submit informal proposals, ideas, or 
suggestions you might have on any of these topics. 

Important Dates 

Extended Abstract Deadline: June 29, 1992 

Acceptance Notification: July 20, 1992 

Final Papers Received: August 31, 1992 

Contact Information 

Submit electronic copy of extended abstracts 
to: 
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Trent Hein 

XOR Computer Systems 
2525 Arapahoe, Suite E4-264 
Boulder, Colorado 80302 
(303) 440-6093 
trent@xor.com 

Program Committee 

Trent Hein XOR Computer Systems 

(program chair) 


Rik Farrow 
Jeff Forys 
John Hardt 
Herb Morreale 
Pat Parseghian 
Jeff Polk 


UNIX World 
University of Utah 
Martin Marietta Astronautics 
XOR Computer Systems 
AT&T Bell Laboratories 
Sun Microsystems 


Request for Proposals to Chair 1993 LISA Conference 


The usenix Association is once again seek¬ 
ing proposals from people interested in chairing 
its seventh LISA conference, to be held sometime 
in the Fall of 1993. Because attendance at this 
event is expected to be high, a Chair must be 
chosen soon so that appropriate venues can be 
reserved. 

We are seeking an energetic person with the 
following qualifications: 

• Good administrative and planning skills 

• Experience in the administration of large 
installations 

• Good public speaking skills 

• Knowledge of timely and appropriate topics 
in the field 

• Ability to solicit good panel members and 
appropriate speakers 

• Attendance at previous LISA workshops/ 
conferences 

• Time to invest to insure success of the con¬ 
ference 

Proposals should be brief (1-2 page) and 
should include the following: 


Statement of Purpose (e.g., why should we have 
another one?) 

Form of submissions (e.g., abstracts, extended 
abstracts or full papers?) 

Format (e.g., 2 or 3 days of technical sessions, 
panel sessions, etc.) 

List of topics to be addressed (as in the call for 
papers) 

Special features (such as having tutorials, BOFs, 
vendor demos) 

List of potential program committee members 
and/or a co-chair* 

Biography and references 

* While most usenix conferences have had 
an individual chair, proposals requesting a co- 
chair and/or small program committee are wel¬ 
come. 

Proposal due date: March 15, 1991. 

Please address all inquiries and proposals to 
the Association’s executive director, Ellie Young 
(ellie@usenix. org). 
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Call For Papers 

File Systems Workshop 

Ann Arbor, Michigan, May 21-22, 1992 


The usenix Association and the University 
of Michigan’s Center for Information Technology 
Integration are sponsoring a workshop on file 
systems, to be held on May 21 and 22, 1992, on 
the campus of the University of Michigan. 

The goals of the workshop are to bring to¬ 
gether researchers and practitioners on all aspects 
of file systems, including: 

• file system performance measurement and 
models; 

• WORM and other optical systems; 

• log-structured, RAID, and other high- 
performance systems; 

• mass-storage and archival systems; 

• support for replication, consistency, and 
mobility, in distributed systems; 

• naming and location in very-large distrib¬ 
uted file systems. 

Workshop participants will be invited to 
present formal papers or informal “works-in- 
progress. There will be opportunities to identify 
and discuss trends, themes, and theoretical and 
practical aspects of file systems research and de¬ 
velopment. 

Call For Papers 

You are invited to submit original papers 
from any area related to file systems for presen¬ 
tation at the workshop and inclusion in the pro¬ 
ceedings. Several categories of papers will be con¬ 
sidered: 

• original and unpublished research reports; 

• reports of innovative applications of current 
technology to new problem domains; 

• position papers on controversial points of 
practical or theoretical interest. 

There will be opportunities for “less pol¬ 
ished” papers to be presented in the workshop 
sessions. 

Five copies of a full paper or extended ab¬ 
stract should be submitted to: 


Workshop on File Systems 

Center for Information Technology Integration 

The University of Michigan 

519 W. William Street 

Ann Arbor, MI 48103-4943 

Papers should include an attached separate 
front sheet describing: 

the title of the paper, 

the name(s) of the author(s), 

affiliation, 

mailing address, 

telephone, telefax and Electronic-mail numbers. 

Papers will be selected by the Program Commit¬ 
tee based on originality, relevance, and impact. 

Important Dates 

Manuscripts due: March 15, 1992 

Program decision: April 1, 1992 

Camera-ready copy due: April 15, 1992 

Organization 

Working sessions will consist of 15-20 sub¬ 
mitted papers, presented in 20 and 30 minute time 
periods. 

Program Committee: 

Peter Honeyman (CITI, University of Michigan) 
Michael L. Kazar (Transarc) 

Larry McVoy (Sun Microsystems) 

Mendel Rosenblum (Stanford University) 

Liuba Shrira (MIT) 

Local Arrangements: 

Carol Kamm (CITI, University of Michigan) 
Judy DesHarnais (usenix Association) 

Further Information 

For further information, contact: 
workshop@citi. umich. edu. 

+ 1 313 763 4403 (Tel) 

+ 1 313 763 4434 (FAX) 
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Preliminary Announcement and Call for Papers 
The Third USENIX UNIX Security Symposium 
Baltimore, MD 
September, 14-17 1992 

In cooperation with 

The Computer Emergency Response Team (CERT) 


The goal of this symposium is to bring to¬ 
gether security practitioners, system administra¬ 
tors and system programmers, and anyone with an 
interest in computer security as it relates to net¬ 
works and the UNIX operating system. The sym¬ 
posium will consist of tutorials, invited speakers, 
technical presentations, and panel sessions. 

This will be a three-day, single-track sympo¬ 
sium. The first day will be devoted to tutorial 
presentations. The following two days will include 
technical presentations and panel sessions. There 
will also be two evenings available for birds-of- 
a-feather sessions and work-in-progress sessions. 
The dates and location of this symposium have 
not yet been determined. 

Papers are being solicited in areas including 
but not limited to: 

• User/system authentication 

• File system security 

• Network security 

• Security and system management 

• Security-enhanced versions of the UNIX op¬ 
erating system 

• Security tools 

• Network intrusions (including case studies 
and intrusion detection efforts) 

Important Dates 

Extended abstracts due May 

Notification to authors: June 

Camera-ready papers due July 


15, 1992 
15, 1992 
31, 1992 


Send seven copies of each submission to the 
program chair: 

Edward DeHart 

Computer Emergency Response Team 
Software Engineering Institute 
Carnegie Mellon University 
Pittsburgh, PA 15213-3890 
(412) 268-6179 
ecd@cert. sei. emu . edu 

Program Committee 

Ed DeHart (Program Chair) 

Computer Emergency Response Team 

Matt Bishop 

Dartmouth College 

Bill Cheswick 

Bell Laboratories 

Ana Maria De Alvare 
Silicon Graphics , Inc. 

Jim Ellis 

Computer Emergency Response Team 
Barbara Fraser 

Computer Emergency Response Team 
Ken van Wyk 

Computer Emergency Response Team 
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Pre-Announcement and Call for Papers 
USENIX C++ Technical Conference 
Portland, Oregon, August 10-13, 1992 


usenix is pleased to host its Fifth C++ Con¬ 
ference in Portland, Oregon, August 10-13,1992. 
Monday and Tuesday will offer tutorials; Wednes¬ 
day and Thursday are technical sessions. This 
announcement provides early information about 
the schedule of events as well as persons to con¬ 
tact for further information. 

Schedule of Events 

Tutorials , August 10-11 

Introductory and intermediate tutorials will 
be provided on the C++ language, libraries, and 
environments. Please contact the program chair if 
you wish to propose to give a tutorial or to suggest 
a topic you would like to see covered in a tutorial. 

Technical Sessions , August 12-13 

Topics for the technical sessions will cover 
the spectrum of recent research, development, 
and experience developing C++ software. Papers 
are solicited on all aspects of C++, including: 

Compilation/Interpretation 
Class Libraries and Frameworks 
Databases and persistence 
Distributed programming 

Programming environments (including design and 
analysis) 

Standardization and internationalization 
Experience (including maintenance and reuse) 

Submissions 

Extended abstracts of at most 2500 words (10 
pages double-spaced) should be submitted elec¬ 
tronically (PostScript, troff, or TeX) or eight (8) 
copies on paper to the program chairman by 

March 20, 1992, 


Authors will be notified of acceptance by 
May 15, 1992 and final camera-ready papers are 
due June 19, 1992. 

Relevant Dates 

Abstracts Due: March 20, 1992 

Notification of Acceptance: May 15, 1992 

Final Papers Due: June 19, 1992 

Queries about the technical program and all 
submissions should be directed to the program 
chairman: 

Jonathan E. Shopiro 

UNIX System Laboratories, Inc. 

184 Liberty Corner Road, Room 4N-C05 
Warren, NJ 07059-0908 USA 
Phone: (908) 580-4229 
Fax: (908) 580-5631 
Internet: shopiro@usl.com 

Technical Program Committee 

Jonathan E. Shopiro, UNIX System Laboratories 
(Chair) 

Dag M. Bruck, Lund Institute of Technology, 
Sweden 

Theodore C. Goldstein, Sun Microsystems Lab¬ 
oratories 

Keith Gorlen, National Institutes of Health 
Brian M. Kennedy, Texas Instruments 
Dmitry Lenkov, Hewlett-Packard 
Mark Linton, Silicon Graphics 
Scott Meyers, Brown University 
Barbara E. Moo, AT&T Bell Laboratories 
Martin O’Riordan, Microsoft 
Jim Waldo, Hewlett-Packard 
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Workshop on Micro-Kernels and Other Kernel Architectures 

Seattle, Washington, April 27-28, 1992 


This workshop is aimed at comparing and 
contrasting existing micro-kernels and their 
macro-kernel counterparts. Industry pundits are 
claiming that microkernel technology is the next 
step in kernel design. A detailed technical inves¬ 
tigation of the microkernel technology will be 
made to discover whether the claims have merit 
or are just this year’s buzz word. Our intent is to 
identify micro-kernels strengths and weakness in 
comparison to each other and to the macro- 
kernels that they hope to replace. The compar¬ 
isons will include functionality, modularity, ease 
of extension, maintainability, and performance. 


The first day will be devoted to talks of a 
tutorial nature on currently important microker¬ 
nels and other kernels. Talks have already been 
committed from: 


PLAN 9- 
MACH- 
CHORUS- 
AMOEBA - 
MICROSOFT NT 


Dave Presotto 
AT&T Bell Laboratories 
Rich Graves 

Carnegie Mellon University 
Marc Rozier 
Chorus Systemes 
Robbert Van Renesse 
Cornell University 
—Dave Cutler 
Microsoft 


The second day is a peer-reviewed technical 
track presenting original work on all aspects of 
microkernels or kernel architecture. Presenta¬ 
tions range from formal research reports to prac¬ 
tical problem-solving sessions, and will be pub¬ 
lished in the proceedings. 

Pre-registration materials containing the pro¬ 
gram and hotel reservation information will be 
mailed to the usenix mailing list late February, 
1992. If you did not receive this announcement 
directly and wish to be on the list for receipt of 
these materials please contact: usenix Confer¬ 
ence Office, Telephone 714-588-8649, 22672 Lam¬ 
bert St., Ste 613, El Toro, CA 92630; EMAIL: 
conference@usenix.org 

Program Committee: 

Lori S. Grob, Program Chair 

Chorus systems 

Edward D. Lazowska 

University of Washington 

Robbert van Renesse 

Cornell UniversityIVrije Universiteit 

Avadis Tevanian, Jr. 

NeXT Computer, Inc. 
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EurOpen & USENIX Spring 1992 Workshop 

April 6-9, 1992, Jersey, Channel Islands, UK 


The Spring 1992 event will be held in con¬ 
junction with the usenix Association. This joint 
venture to be held on the island of Jersey will be 
the first event of this kind for EurOpen and us¬ 
enix. 

One of the major goals of Open systems is to 
support the distribution and mobility of data, us¬ 
ers and processing. The purpose of the Spring 
1992 EurOpen and usenix Workshop is to iden¬ 
tify the challenges of this goal and to discuss 
possible solutions. The workshop will address is¬ 
sues of concern to the system designer, developer, 
manager, administrator and end-user. 

Tutorials for this joint event will be held on 
Monday, April 6 and in the morning of Tuesday, 
April 7. The Conference/Workshop will be held 
from 2:00 p.m. on Tuesday and will finish Thurs¬ 
day afternoon. 

Tuesday, April 7 

Session: Opening Session (Frances Brazier, 
Chair) 

Keynote: Portability (Mike Banahan, Instruction 
Set, UK) 

Session: From Portability to Porting (Patrick Bur- 
baud, Chair) 

Software Preporting (Marc Poinot, SEXTANT 
Avionique, FR) 

Focusing on Portability (Frances Ducroux, 
AFUU, FR) 

Wednesday, April 8 

Session: Portability and Standards (Patrick Bur- 
baud, Chair) 

Keynote: Jean Hyenne, AFNOR, FR 
Session: Standard Environments (Frances Bra¬ 
zier, Chair) 

Certifying Binary Applications (Donald 
Lewine, Data General, USA) 
Applications POSIX.l Conformance Testing 
(Derek M. Jones, Knowledge Software 
Ltd, UK) 


X Is The Worst Window System (Except For 
All The Others) 

(Berry Kercheval, Intelligent Decisions 
Corp, USA) 

Session: Software Patents (Barry Shein, Chair) 
The Problem With Software Patents (Rich¬ 
ard M. Stallman, Free Software Founda¬ 
tion, USA) 

Session: Practice (David Tilbrook, Chair) 

Practical Problems With Porting Software, 
(Brian O’Donovan, Digital Inti, Ireland) 
PHOENIX: A Health Information System 
Based on usenix Client Server (Reinhardt 
Koller, Austria) 

What Makes GNU Software So Portable? 

(Steve Chamberlain, Cygnos, USA) 
EUnet Status and Direction (Glenn Kowack, 
EUnet, NL) 

BOFS: EUnet, Copyright Legislation, Stan¬ 
dards 

Thursday, April 9 

Topic: Wombats and Porting (Barry Shein, Chair) 
Keynote: Andrew Hume, Bell Labs, US r A 
Session: Paradigms (David Tilbrook, Chair) 
Inter-Fashion Portability (Barry Shein, Soft¬ 
ware Tool & Die, USA 
Camera: Cooperation in Open Environments 
(Gert Florijn, SERC, NL) 

Are We Smart Enough for C++? (Axel 
Schreiner, University of Osnabrueck, 
Germany) 

Portability Panel (Frances Brazier, Chair) 

Reserve Papers 

Distributed System and Security Management 
with Centralized Control (Chii-Ren Tsai) 
Porting under usenix - Problems Areas and a 
Proposed Strategy (David Jackson) 

For more complete information on this 
event and to receive registration materials, 
please contact the usenix executive’ office 
(office@usenix. org). 


January/February 1992 


11 



;login: 17:1 


Calendar of UNIX-Related Events 


1992 Mar 4-7 

Computers in Libraries 

Westport, CT 

1992 Mar 11-18 

CeBIT 92 

Hannover, Germany 

1992 Mar 24-27 

AFUU 

Paris, France 

1992 Mar 26-27 

*SEDMS III 

Newport Beach, CA 

1992 Apr 6-9 

EurOpen/USENIX 

Jersey, UK 

1992 Apr 6-10 

IEEE 1003 

Atlanta, GA 

1992 April 27-28 

*Micro-Kernel 

Seattle, WA 

1992 May 4-8 

DECUS 

Atlanta, GA, 

1992 May 18-22 

ISO/IEC CJT1 SC22 WG15 


1992 May 21-22 

*File Systems 

Ann Arbor, MI 

1992 Jun 2-4 

UNIX EXPO West 

Anaheim, CA 

1992 Jun 8-12 

USENIX 

San Antonio, TX 

1992 Jun 22-24 

Sun User Group 

Washington, DC 

1992 Summer 

UKUUG 

Belfast, Northern Ireland 

1992 Jul 13-17 

IEEE 1003 


1992 Aug 10-14 

*C++ 

Portland, OR 

1992 Sept 8-11 

AUUG 

Melbourne, Australia 

1992 Sept 14-17 

♦Security III 

Baltimore, MD 

1992 Oct 6 

ISO/IEC JTC1 SC22 WG15 

Denmark 

1992 Oct 19-23 

*LISA VI Conference 

Long Beach, CA 

1992 Oct 19-23 

IEEE 1003 


1992 Oct 26-30 

Interop 

San Francisco, CA 

1992 Nov 25-27 

EurOpen/UniForum 

Utrecht, The Netherlands 

1992 Dec 

UKUUG 

Manchester, UK 

1993 Jan 11-15 

IEEE 1003 


1993 Jan 25-29 

*USENIX 

San Diego, CA 

1993 Mar 16-18 

UniForum 

San Francisco, CA 

1993 Mar 24-31 

CeBIT 93 

Hannover, Germany 

1993 Apr 5-19 

IEEE 1003 


1993 Apr 26-30 

EurOpen 


1993 Jun 21-25 

♦USENIX 

Cincinnati, OH 

1993 July 12-16 

IEEE 1003 


1993 Oct 25-29 

Interop 

San Francisco, CA 

1993 Autumn 

EurOpen/UniForum 

Utrecht, The Netherlands 

1994 Jan 17-21 

♦USENIX 

San Francisco, CA 

1994 Feb 14-17 

Uniform 


1994 Mar 16-23 

CeBIT 94 

Hannover, Germany 

1994 Mar 23-25 

UniForum 

San Francisco, CA 

1994 Apr 18-22 

EurOpen 

Dallas, TX 

1994 Jun 6-10 

*USENIX 

Boston, MA 

1994 Sep 12-16 

Interop 

San Francisco, CA 

1994 Autumn 

EurOpen/U niForum 

Utrecht, The Netherlands 

1995 Jan 19-20 

*USENIX 

New Orleans, LA 

1995 Feb 21-23 

Uniforum 

Dallas, TX 

1995 Jun 19-23 

*USENIX 

San Francisco, CA 

1996 Jan 22-26 

♦USENIX 

San Diego, CA 

1996 Mar 12-14 

Uniforum 

San Francisco, CA 


*USENIX conferences, workshops, symposia, and mini-conferences 
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Report on the October 1991 IEEE POSIX Meeting for EurOpen 

Stephen R. Walli <stephe@mks.com> 

EurOpen Institutional Representative 


The October meeting of the ieee posix com¬ 
mittees was a strange mixture of administrivia and 
crankiness. Perhaps it was merely my outlook on 
the latter. There was no central theme for the 
week, as there has been in the past with items such 
as the GUI Wars. 

The foundation of posix was under attack 
this week in some interesting and possibly nec¬ 
essary ways. These discussions concerned options 
and testability, and options (different) and pro¬ 
filing. The Project Management Committee 
(PMC) made some carefully worded statements 
about the continued sponsorship of P1201 
(Graphic User Interfaces), the Sponsor Executive 
Committee (i.e., tcos-ss Governing Board) 
meeting was over in record time Thursday night, 
and we all went home, exhausted as usual. 

Other items of note include a debate over the 
upcoming European ieee posix meeting next 
Fall, and some new work items for consideration. 

Let’s start with the really interesting bits. 


Profiles and POSIX. 1 

There was considerable discussion in the 
posix. l working group (Base Interfaces) sur¬ 
rounding the old issue of chopping the standard 
up into chunks of functionality. This discussion 
centers around the issue of whether or not a pro¬ 
file can point to pieces of the POSIX.l standard. 

The posix. 4 (Real-time extensions) docu¬ 
ment has its functionality divided up into separate 
sections, each called out by an option name. For 
example, if an implementation supports binary 
semaphores then the symbol POSIX BINA¬ 
RY __ SEMAPHORES is defined. This makes it very 
easy for a profile to point to a piece of required 
functionality in the real-time document. 

posix. l only supports a few such options for 
conforming implementations: NGROUPS_MAX, 
_POSIX_JOB_ CONTROL, and _POSIX- 
_CHOWN_RESTRICTED. 


The posix. 13 real-time profiling group wants 
the posix. l standard further optionized to allow 
its functionality to be called out separately, such 
as an option for the file system, an option for 
process control, and so on. This would allow the 
real-time embedded profile to specify a posix. l 
style file system, but not require posix. l style 
process control. The embedded profile cares 
about threads, or possibly a single process. Noth¬ 
ing so “cumbersome” as multiple processes is 
required. 

There are members of posix. i who com¬ 
pletely disagree with this view of the standard. 
posix. l defines a portable programming interface 
which serves a broad range of general applica¬ 
tions. It is viewed as a minimal set. Nothing may 
be removed, posix. l can never be subsetted. 

Part of this has to do with the sanctity of the 
term “posix”. To the original standards devel¬ 
opment group, “posix” means posix. l. If you 
come from the POSIX.2 Shell and Utilities group, 
it means a POSIX.2 Shell and Utilities environ¬ 
ment, which doesn’t necessarily require a posix. l 
system underneath it. Some people are magnan¬ 
imous enough to recognize it to mean a posix. l 
implementation with a posix. 2 Shell, and so on. 

There is a real concern that anything else isn’t 
posix, nor can it use the name posix. A terrible 
vision is painted of the existing DOS environ¬ 
ment, i.e., a loader and simple file system, being 
allowed to call itself posix by making functionality 
optional like process control. 

Coming relatively recent to the IEEE POSIX 
standards development world, (I’ve only been 
mired in the muck for two years,) I quickly 
learned to use the term “posix” to mean a family 
of standards development projects. Indeed, this is 
the informal definition discussed in the posix. 1 
standard’s introduction. If one wants to discuss 
posix. l interfaces, one talks about “POSIX.l”. 
Likewise, if one is discussing POSIX.6 extensions, 
one refers to “posix.6”, and so on. This level of 
naming is required to remove ambiguity. 
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There is also no way to keep marketing de¬ 
partments clear on this. They will continue to 
misuse and abuse the term “posix”. There is no 
protection for an ignorant consumer. The stan¬ 
dard legislates what needs to be provided to claim 
posix.i conformance. It cannot police the market 
place. 

There is a genuine technical issue with di¬ 
viding up the POSIX.I standard. The division 
would need to be extremely clean and concise. 
Relevant definitions from one section would need 
to be carried with functionality discussed in the 
other sections. Any cross referencing would need 
to be handled extremely carefully. Considering 
the current organization and wording used 
throughout the posix.i standard, it would not be 
an easy job to pick out new options. 

This discussion will likely carry on for some 
time as other profiling work attempts to impact 
POSIX.I. Already there are profile working groups 
for supercomputing, transaction processing, real¬ 
time systems, multi-processor systems, and a gen¬ 
eral multi-user this-is-what-UNix-looks-like pro¬ 
file. 

I don’t believe anything should prevent a 
future IEEE posix standards working group, 
posix.42 for example, developing some narrow 
but well defined application environment profile 
for their application domain which leverages off 
of the POSIX.I domain. Implementors will imple¬ 
ment and claim conformance to posix.42. Appli¬ 
cations developers will build portable applications 
using the interfaces in the posix.42 profile. If 
posix.i can subset carefully enough to cleanly and 
clearly describe pieces of functionality, it should. 
Future applications development/procurement 
profiles, such as the U.S. government FIPS 151-1 
on posix.i, may indeed be based on the posix.18 
general multi-user profile. Simple. But then noth¬ 
ing is ever simple in posix. 

OPTIONS and options 

posix.i allows implementation variance in a 
number of ways. The primary implementation 
options are a well defined, explicit method of 
allowing implementation variance. These are 
all named (e.g., _ POSIX_ CHOWN_ RE¬ 

STRICTED), and have thus been nick-named 
“Big-O” options. 

The term “implementation defined” clearly 


allows an implementation to do anything it 
chooses, although there are documentation re¬ 
quirements. Even “unspecified” and “undefined” 
are well described. Then things get muddy fast. 

Some facilities are not necessarily manda¬ 
tory, and the choice of whether to implement or 
not is indicated by the use of the term “may”. For 
example, an implementation may define certain 
environment variables, and if it does, they shall 
mean a certain thing. 

For other features, an implementation is al¬ 
lowed a restricted choice between two behaviors, 
indicated by phrasing similar to “may do A or B”. 
For example, the behavior of an interrupted 
read() after successfully reading some data is to 
either return -1 and set errno to [EINTR] or the 
read() returns the number of bytes read to that 
point. 

These later two examples are deemed 
“messy”, by the posix. 3.1 (Test Methods for 
posix.i) working group, and are being docu¬ 
mented. They’ve been nick-named “little-o op¬ 
tions”, as some people feel they should more 
explicitly be called out as selectable options. 

The other side of the discussion argues that 
these are items which no portable application 
should care about. The wording of the standard 
allows for the implementation to choose its own 
path. It acts as a caveat to the application devel¬ 
oper to not depend upon the exact nature of the 
behavior. 

This discussion will likely heat up over the 
next meeting or two. 

P1201 Continues 

When last we left our story, the Project Man¬ 
agement Committee (PMC) of the ieee posix 
sponsor executive committee (SEC) was left to 
recommend a suitable fate for the P1201 project 
on graphic user interface standards. A motion had 
been made to withdraw sponsorship from the 
project. 

P1201 consists of two projects. P1201.1 is 
developing a windowing user interface toolkit 
specification. It has a long history of bloodshed 
between Open Look and OSF/Motif supporters. 
P1201.2 is developing a guidelines document on 
recommended drivability practice. A style guide 
for “feel”, rather than “look”. 
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Separate competing project requests were 
brought forward in the Spring 1991, one to stan¬ 
dardize the OSF/Motif API and Style Guide, and 
the other to standardize the Open Look API and 
Style Guide. The ieee Standards Board (posix’s 
parent committee) considered that the function¬ 
ality overlap between the two proposed work 
items and also with the work of P1201.1, was an 
insufficient reason to refuse project sponsorship. 

At the July 1991 meeting, the posix working 
groups refused to undertake sponsorship of these 
competing projects for other reasons. The work 
was considered too immature to standardize it. It 
was then moved that sponsorship be removed 
from P1201 because it suffers the same flaws. This 
motion was handed to the PMC to recommend 
action for the October meeting. 

P1201.1 requested a revision of its scope of 
work, and is working toward a simpler higher- 
level API specification. They have made real 
progress over the past two meetings (July and 
October) with the contentious members off chas¬ 
ing their own project requests. (Incidentally, 
these project requests are still being pursued in 
dank dark corners of the ieee standards hierar¬ 
chy.) The revised scope was recommended for 
approval, and the project will be reviewed again 
in three meetings. 

P1201.2 has been making steady progress all 
along. They are hoping to go to ballot in the not 
too distant future. Continuation of their work was 
recommended. P1201 is allowed to proceed. It all 
seemed entirely to quiet and straight forward, 
considering the history of the past two meetings. 
Maybe weTe maturing. 

To pull the plug on these working groups at 
this point would be a mistake. In a few years time, 
there will clearly be a need for such a standard, 
and the technology will be very mature (read: ripe 
for standardization). It will be very difficult to get 
employers to support such an effort, spending the 
money to keep people involved, if the initial effort 
is closed without anything tangible to show for it. 

European Meeting in October 1992 

The IEEE has a desire, as a “transnational” 
organization, to have its standards development 
groups meet every other year somewhere other 
than the United States. The intent is to gather 


international input into its standards development 
process. This is very important to posix, consid¬ 
ering its ISO development stream as an interna¬ 
tional standard being developed by a national 
member body. (The American National Stan¬ 
dards Institute, ANSI, delegated responsibility 
for the posix standard’s development back to the 
IEEE.) 

There was a lot of resistance to meeting in 
Europe in the Fall of 1992. The problems center 
around corporate approval and money. 

Many corporate authorities don’t view trips 
to Europe as “work”. They still think posix is 
some kind of conference. They don’t appreciate 
that it is a standards development working group. 

Many American hotels, large enough to sup¬ 
port the 350 working group members with about 
25 to 30 meeting rooms, do not charge for the 
meeting rooms. They make their money from 
serving lunch and coffee. European hotels appar¬ 
ently charge for meeting rooms regardless of 
lunch and room bookings. This means that the 
meeting registration will likely be at least twice 
the normal $250 US. Add to this a trans-Atlantic 
airfare, and a higher per deum, and managers 
start getting real uncomfortable approving the 
funds. 

Historically, the last meeting was held in 
Brussels in October, 1989. It did not draw a lot 
of European response. The European response 
that it did draw was not sustained past that meet¬ 
ing in many cases. Many working groups are loath 
to go the effort of gaining corporate approval for 
a European meeting, if it’s not going to bring in 
the desired European participation. 

On the other hand, if a large European con¬ 
tingent does show up, some posix working groups 
are concerned that their work agendas will be 
affected, while they adjust to bringing an influx of 
new blood up to speed on the issues. They want 
to have their cake and eat it too. 

The current decision is to continue to pursue 
a meeting in Europe. A likely candidate country 
is the Netherlands. Ideas to defray some of the 
costs include: 

• holding seminars prior to the posix working 
group meetings on posix related topics, 

• requesting the IEEE Computer Society pick 
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up the additional expenses, (on the order of 
$70,000 US.) 

* charging individual attendees the additional 
money to attend. 

I would love to hear from EurOpen members 
any suggestions, ideas and preferences regarding 
this subject. How high is European interest in an 
IEEE posix working group meeting? 

New Work Items for Consideration 

A number of new topics are being raised as 
potential candidates for standardization by the 
ieee’s Technical Committee on Operating Sys¬ 
tems em Standards Subcommittee (tcos-ss). 
This is the full proper name of the committee 
responsible for the posix working groups. 

Two of these candidates come from outside 
of the IEEE realm. The SPECmark consortium has 
approached the ieee with the idea of making the 
SPECmark performance benchmarks an industry 
standard. There may be a formal presentation by 
the SPECmark consortium at January’s IEEE 
POSIX meetings, but the general feeling was that 
standardization of this work belonged elsewhere. 

A second outside proposal was from the 
Rock Ridge group. These people are standard¬ 
izing on an optical disk standard. (This work 
should not be confused with the ANSI X3B11.1 
WORM standard work. Please see Andrew Hu¬ 
me’s X3B11.1 working group report in the Jan./ 


Feb 1992 issue of ;login: or in comp.std.unix.) 
There is the desire to place a posix. l file system 
on a Rock Ridge disk, and therefore an interest 
in input from the POSIX working groups. It was 
again felt that this work would better be done at 
arm’s length, with appropriate liaisons in place. 

The final new work item came from within. 
The Distributed Systems Steering Committee 
(DSSC), which overseas all of the network related 
standards in tcos-ss, has proposed forming a 
working group to develop a standard for secure 
distributed computing. Depending upon who you 
talk to, this means Kerberos or definitely-not- 
Kerberos. 

It will likely start as a simple Birds-of-a- 
Feather meeting at the January ieee posix meet¬ 
ing. If there’s enough interest, a real study group 
will be formed to meet at the April posix meeting 
for the week. The result of such a meeting would 
be a project authorization request (PAR) to be 
presented to the Project Management Committee 
(PMC) in July. The PMC is a sub-committee of 
the Sponsor Executive Committee (SEC), which 
is the controlling committee of tcos-ss. 

If the PMC recommends sponsorship, the 
SEC will ratify it with a vote. The study group 
would become a real standards working group of 
tcos-ss, with its first formal meeting as “early” as 
the October posix meeting. Thus are standards 
born. 
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An Update on UNIX-Related Standards Activities 

Stephen R. Walli 

Report Editor, USENIX Standards Watchdog Committee 


What is POSIX.0 and why isn’t it in ballot? 

There is a lot of confusion surrounding the 
posix.0 working group. There are many different 
co-ordination problems in a set of related projects 
the size of POSix. 

* How will all the new system interface ex¬ 
tensions like real-time, security and trans¬ 
parent file access fit into and onto POSix l, 
the base interface standard? 

* How will profiles layer on top of the base 
interfaces? Especially considering the cur¬ 
rent dynamic state of some of these docu¬ 
ments and that no one knows how they 
completely integrate? 

* How do test methods layer onto the base 
interfaces? 

* How will language independent specifica¬ 
tions map the C-based documents, and how 
are test methods affected? 

One might presume that the POSIX.0 working 
group was addressing all of these thorny prob¬ 
lems. They are not. Over time several ad hoc 
committees and steering committees have formed 
to address various symptoms of these problems. 

posix.0 is building an overall guide book to 
open systems environments, the “Guide to Open 
Systems Environments”. It is supposed to act as 
an informative guide to all of the issues involved 
in open systems, developing a model of how all 
these standards and technologies inter-relate. It 
will enable the design of a profile by an applica¬ 
tion systems analyst. The profile will be used for 
systems procurement, systems design and devel¬ 
opment. This would be a very useful document to 
have in existence. ISO is considering using 
POSix.O’s work as an ISO technical report. 

Problems arise with the resources of the 
working group, posix.0 has long been labelled the 
“room with the suits.” It is where management 
and strategic planners go when they attend posix 
meetings. These people feed back to their organ¬ 
isations how open systems technologies will be 
used. They help build and maintain the business 


case for the rest of our participation. Their goal 
in building the guide is a necessary one, and an 
essential part of the overall industry move to open 
systems. 

They have recognised that their strengths are 
strategic and not technical. They have requested 
that other working groups provide the detailed 
technical resource that is needed to develop and 
review their respective parts of the guide. This is 
where the problems begin. 

The other working groups are already 
stretched very thinly. They are busy working on 
the interfaces and profiles they desire to be stan¬ 
dardized. They are also dealing with the added 
quality assurance requirements like language in¬ 
dependent specifications and test methods. They 
have their own resource problems. 

The working groups really are a group of 
fiefdoms, each addressing their area of technical 
experience and expertise, serving their part of the 
industry. While they generally appreciate the 
needs of the POSix.0 working group, they haven’t 
the bandwidth to service those needs. They’re 
waiting for the “Guide” to go to ballot, knowing 
that they have to comment then or forever remain 
silent. 

posix.0 has existed for almost four years. 
They are up to draft 14 of their document. They 
are only now trying to go to mock ballot. In any 
other ieee standards body outside of the tcos-ss 
sponsored posix family, people might begin ques¬ 
tioning their existence. 

posix.0 requested and received the support 
of the TCOS-SS Sponsor Executive Committee to 
force other working groups to attend the “archi¬ 
tecture” co-ordination meetings held once a week 
during posix working groups. I was posix. 4’s stuc- 
kee. 

I witnessed two generally prevailing attitudes 
in the October meeting: compliance by avoidance 
or compliance with complaint. Some working 
group members used the meeting to sit quietly 
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getting caught up on other things, either reading 
they had brought with them, or meeting quietly 
with other people they had to co-ordinate with 
that week. Others were just upset that they were 
spending valuable time in a working group other 
than their own, commenting on a document that 
was not their concern. 

Time is a priceless commodity at IEEE POSIX 
meetings. Key people within individual working 
groups, and the people with more global views of 
POSIX, are already stretched too thinly to partic¬ 
ipate in a development effort in another room. 

As long as the balloting cycle remains for 
posix.O, I don’t believe there will be active par¬ 
ticipation from outside of the posix.O working 
group. Mock ballot is not real. The people that 
should comment on the document will still wait 
for real balloting to start. They are just too busy. 

It is very difficult to submit one’s hard work 
for comment and criticism by the anonymous ig¬ 
nominy of a balloting group. Often, balloting 
group members were not a part of the working 
group. They were not part of the hard discussions 
which shaped initial drafts of the document. They 
are not always polite and constructive in their 
criticisms. 

Balloting, however, is not a “checkpoint” or 
milestone. Documents are not presented as com¬ 
pleted technical or business reports, as they might 
be in our normal working environment. Balloting 
is an entire phase in the standards development 
process. The POSIX.O guide will be shaped by the 
balloting process. This is a fact. One only has to 
look at the existing examples of posix. l, and 
POSIX.3 (Test Methodologies). The chairs of the 
posix. 2 (Shell), posix. 4 (Real-time), and the lan¬ 
guage bindings (Fortran and Ada) working groups 
have all seen their documents re-shaped in ballot. 
This has happened over a balloting period of up 
to a couple of years. 

Attempting to perfect the document before 
ballot only delays the process of developing this 
necessary guide. The Guide is not something to 
be presented to a balloting group for approval. It 
is presented to have it critiqued, corrected, and 
shaped into the best possible, consensus built doc¬ 
ument it can be. 

The posix.O guide should be sent to ballot. 
Only then will it receive the genuine comment and 


constructive criticism it requires to become the 
educational guide the commercial world is looking 
for. 

Report on POSIX.O: The Guide to Open 
Systems Environments 

Kevin Lewis <klewis@gucci.enet.dec.com> 
reports on the October 21-25 meeting in Parsip- 
pany, NJ: 

The October meeting for posix.O was quite 
focused: get ready for the mock ballot. This re¬ 
quired the group to pass through the document 
four times, each time with a deeper level of scru¬ 
tiny. The level of consensus was quite high given 
that the group has worked diligently over the last 
year towards this goal. (Ya know, it’s funny how 
a “line in the sand” can make a group of people 
come together . . .). 

Two major changes were made to the ballot. 
The Software Development Environments sec¬ 
tion was moved to an appendix. The Fault Man¬ 
agement section was merged into the section on 
Information System Management. The remaining 
changes were editorial. 

The mock ballot will start in mid-November 
and end on January 7. Our overall objective is to 
begin the ballot resolution at the January meet¬ 
ing. We will also begin drawing up plans for the 
formal ballot, which right now is scheduled to 
begin in July. 

There is still an issue dogging posix.O. People 
still presume that POSIX.O is where one goes to find 
out how all of the posix. n standards fit together. 
We have determined and stated several times that 
it is not the place. The guide’s purpose goes be¬ 
yond the efforts of the current POSIX groups. It 
maps existing and emerging standards that are 
well outside the posix effort in such as way as to 
reflect the general requirements of a complete 
open system, with the posix standards playing a 
key role. 

We do understand the need for this type of 
overview information and see why some people 
assume that posix.O is the place to get it. The 
group intends to discuss this at the January meet¬ 
ing with the objective of pursuing some kind of 
resolution. Off the cuff, we felt that UniForum’s 
“posix Explored” series may already be address¬ 
ing this need. 
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Aside from this, the group is now holding its 
breath to see what kind of response it gets via the 
mock ballot. Stay tuned .... 

Report on POSIX.2: Shell and Utilities 

David Rowley <david@mks.com> reports 
on the October 21-25 meeting in Parsippany, NJ: 

Summary 

POSix.2 (Shell and Utilities) Draft 11.2 closed 
its “changes-only” recirculation ballot on October 
21. The draft received 80% approval, therefore 
posix.2 will not be recirculated until iso com¬ 
ments have been received (sometime in May 
1992). An ieee standard is expected by late sum¬ 
mer 1992. Draft 8 of POSlx.2a (upe) is due out 
early in December. 

POSix.2b (see below) is underway, with the 
first draft distributed to the working group. The 
group continues to wrestle with the new pax ar¬ 
chive format. Most of the time was again spent in 
a joint meeting with POSIX..3.2 (Test Methods for 
POSIX.2) creating test assertions for the document. 
Work on POSlx.2a test methods is scheduled to 
start in January at the Irvine meeting. 

Background 

A brief posix. 2 project description: 

• posix.2 is the base standard dealing with 
the basic shell programming language and 
a set of utilities required for the portability 
of shell scripts. It excludes most features 
that might be considered interactive. 
posix.2 also standardizes command-line 
and function interfaces related to certain 
posix.2 utilities (e.g., popen (), regular ex¬ 
pressions, etc.). This part of POSIX.2, which 
was developed first, is sometimes known as 
“Dot 2 Classic.” 

* POSlx.2a, the User Portability Extension or 
UPE, is a supplement to the base standard. 
It standardizes commands, such as W, that 
might not appear in shell scripts, but are 
important enough that users must learn 
them on any real system. It is essentially an 
interactive standard, and will eventually be 
an optional chapter to a future draft of the 
base document. This approach allows the 
adoption of the upe to trail Dot 2 Classic 
without delaying it. 


Some utilities have both interactive and non¬ 
interactive features. In such cases, the UPE defines 
extensions from the base posix.2 utility. Features 
used both interactively and in scripts tend to be 
defined in the base standard. 

* POSix.2b is a newly approved project which 
will cover extensions and new requests from 
other groups, including the new pax ar¬ 
chive format and the command changes re¬ 
quired to provide an interface to the sym¬ 
bolic link work from POSiXia. 

Together, Dot 2 Classic and the UPE will 
make up the International Standards Organiza¬ 
tion’s iso 9945-2—the second volume of the pro¬ 
posed iso three-volume posix standard. 

POSIX.2 Status 

Resolution of posix.2 Draft 11.2 ballot ob¬ 
jections was completed with 80% approval. The 
final step to becoming an IEEE standard is to 
resolve comments from ISO. Draft 11.2 is also 
registered as iso/iec Committee Document (cd) 
9945-2.2. International balloting continues, and 
iso comments are expected at the May 1992 WG15 
meeting. The Chair of posix. 2 , Hal Jespersen, 
will only produce a Draft 11.3 for recirculation at 
the IEEE level if significant iso problems are en¬ 
countered. Draft 12 would then be produced in 
June of 1992, with the standard approved at the 
next IEEE Standards Board meeting. 

The ieee is experimenting with electronic 
access to standards documents. The current drafts 
of posix.2, posix. 0 , and related documents are 
now available via ftp, courtesy of the ieee and 
Andrew Hume at AT&T Bell Labs 
(andrew® research. att. com). Documents are 
available in both postscript and plain ASCII for¬ 
mats. From a reviewer’s standpoint, it is ex¬ 
tremely useful to be able to grep the drafts. This 
will also increase the number of people with ac¬ 
cess to these materials. I hope the IEEE will ex¬ 
pand this trial. 

POSIX.2a Status 

Draft 7 was produced and recirculated, and 
the ballot closed August 19. Ballot resolution is 
complete, and Draft 8 should be available early 
in December. 
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Draft 8 will also be submitted to iso as a 
Proposed Draft Amendment (PDAM) for even¬ 
tual ballot as iso 9945-2, Amendment 1. Expect 
the approval of POSix.2a as a full-use standard 
anywhere from three to six months after posix.2. 

POSIX.2b Status 

Command interfaces to the posix.la work 
will be a large component of the POSix.2b work. 

Dawn Burnett (usl) has volunteered to write 
up a proposal on modifications to the existing 
posix.2 command set to accommodate symbolic 
links. The proposal will be based on existing Sys¬ 
tem V support. 

David Korn (at&t) suggested creation of a 
new find command, as an interface to the file- 
tree-walking services provided in posix.la. The 
proposal was turned down due to lack of existing 
practice. 

Eric Horner (Unisys) is preparing a proposal 
on adding getsubopts, since many commands 
have the need to process sub-options. The work 
will be based on the System V Release 4 imple¬ 
mentation. 

Karen Schafer, the Chair of POSix.lO (Su¬ 
percomputing Profile) and posix.15 (Supercom¬ 
puting Batch Interfaces), has requested that a 
command interface to the new posix.la check¬ 
pointing service be added. The POSIX.15 working 
group will submit a proposal. 

The Chair mentioned that ISO may possibly 
request that the macro processor m 4 be added to 
POSix.2b. Apparently there is a sizable demand 
from the ISO community. m4 is specified in the 
X/Open Portability Guide. 

Hal Jespersen has volunteered to Chair the 
POSlx.2b group, but has explicitly requested that 
he not chair the corresponding test methods 
work, due to the amount of personal time and 
effort required. Resources to perform this func¬ 
tion will have to be found before test methods 
work can start. At the meeting, Hal Jespersen was 
reconfirmed as Chair of POSIX.2 and POSix.2a. 
The term is for a period of three years. Many 
groups were asked to reconfirm their officers. 


Project Management Committee Review 

Both posix.2 and POSlx.2a were reviewed by 
the Project Management Committee (pmc) in Oc¬ 
tober. Both projects were found to be meeting the 
stated objectives of their respective pars. 

New PAX Archive Format 

The group continued to struggle with the new 
PAXarchive format. Mark Brown (ibm) completed 
revising the current proposal (now part of 
POSix.2b), but the group is having difficulty reach¬ 
ing consensus on the scope of this effort. 

iso would like the new format to include 
some form of filename code set translation facil¬ 
ity, and preferably a file content translation 
scheme. Some members want to go further, and 
add extensive pre- and post-processing services, 
including code set mapping, encryption, and com¬ 
pression.. Hal Jespersen will follow up with ISO to 
determine their exact requirements, but encour¬ 
ages the group to take on a leadership role in 
defining the specifications. 

The general POSIX.2 philosophy of “divide 
and conquer”, each utility performing one func¬ 
tion simply and quickly, does not seem to be in 
effect here. The group is attempting to define 
code set mapping within an archive format, when 
there is no general-purpose mapping utility de¬ 
fined as part of the posix.2 effort. 

X/Open includes the specifications for the 
iconv utility, as well as the iconvQ, icon- 
vopenQ and iconvcloseQ system inter¬ 
faces. Had POSix.2 included these standard ser¬ 
vices for code set translation, creation of the new 
PAX format would be much less contentious. 
posix.2 is often referred to as a “command-line 
interface to system services”. This new pax for¬ 
mat strays from that path (along with the inter¬ 
nationalization utilities “locale” and “locale- 
def”). Brand new functionality should not be 
created at the command level. 

Test Methods 

Tuesday to Thursday were spent writing test 
assertions in a joint meeting between posix.2 and 
POSIX.3.2. The situation has not improved since 
the previous meeting. Confusion continues to 
reign when writing assertions. The requested style 
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guide did not materialize in Parsippany, but the 
group banded together to put the results of their 
guidelines discussion down on paper. This will 
allow the legacy of each meeting to be passed onto 
the next. 

Work continued on reviewing test methods, 
including be, make, Basic Regular Expressions, 
awk and the localedef grammar. 

Either a “Mock Ballot” or a “Request for 
Comment” of the current posix.3.2 draft (Draft 
7) will be distributed at the end of November. 
Comments are expected back by the end of Feb¬ 
ruary. 

Writing test assertions for POSlx.2a will start 
in January 1992. Methodologies for writing in¬ 
teractive test methods (for testing vi, etc.) have 
yet to be developed. It is important some specific 
guidelines be set early on to provide the needed 
consistency. The challenges faced here will likely 
be the foundation for future test methods work, 
such as that required by the Graphical User In¬ 
terface groups. 

Report on 1003,3 POSIX Test Methods and 
Conformance 

Andrew Twigger <att@root.co.uk> reports 
on the October 21-25 meeting in Parsippany, NJ: 

SCCT Matters 

Much of the Steering Committee on Con¬ 
formance Testing (SCCT) discussion centered 
around the manner in which test methods for the 
various additive standards (to posix. l) could be 
combined into a single document. Many of the 
problems in combining test methods relate to the 
manner in which the additive standards use base 
functionality from posix. l in a slightly modified 
manner. For example, the posix.4 (Real time 
extensions) draft standard makes copious refer¬ 
ence to POSIX.l functions and applies them to new 
file types. This means that many of the test as¬ 
sertions contained in posix. l become applicable 
in the new context, while others remain applicable 
only to POSIX.l. Expressing this in a standard 
quickly results in the emergence of a complex 
matrix structure defining the applicability and 
testability of a particular assertion. 

This problem is made worse by the failure of 
the various working groups within posix to clearly 


address the issues of interaction between the stan¬ 
dards. The current philosophy seems to be that 
the first additive standard to be adopted won’t 
have to worry about all of the others that are 
coming later. The problems of integration lie with 
those who are later in achieving adoption. This is 
an unsatisfactory state of affairs and there is need 
for a practical solution to the problem. 

The SCCT is also faced with the issue of 
working groups wanting to quote subsets of the 
interfaces in posix. l. This has already started with 
posix.8 (Transparent file access) which is modi¬ 
fying previously mandated posix. l behaviour. 
There were rumours circulating that one group 
wanted a subset consisting of only four posix. l 
functions. This makes the task of the test methods 
writer much more difficult, since there are far 
fewer functions available to perform a test. If 
subsetting to this level becomes common practice, 
perhaps I will be able to get a conformance cer¬ 
tificate for my watch! 

A great deal of SCCT time was taken up in 
discussing what subsets were allowable and how 
many different options a supplier can choose from 
in providing a conforming system. Much of this 
problem relates to the manner in which POSIX.l 
tried to deal with the differences in traditional 
behaviour and the variety of wording they used in 
the posix. l standard to identify this, posix. 3.1 
(test methods for posix. l) has perpetually strug¬ 
gled with this terminology both in terms of the test 
assertions and the requirements that should be 
placed on a conformance document. I am sure 
that this discussion will continue for several meet¬ 
ings before any conclusion is drawn. I am unsure 
that many people are aware of the consequences 
of dividing standards into lots of optional pieces 
in a manner that becomes difficult for the users to 
understand. 

The SCCT continues to struggle with ideas on 
testing profiles. The profile groups seem very ea¬ 
ger to provide test methods for their profiles, but 
in many cases the manner in which they apply 
underlying standards is unclear. Indeed, in some 
cases the profile is being used as a tool to identify 
the gaps in the base standards rather than there 
being any real hope of the document being for¬ 
warded for ballot before these underlying stan¬ 
dards are complete. 
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POSIX.3.1 

The outstanding ballot objections to the 
POSix.3.1 were reviewed with the balloters during 
the meeting. I believe that a concensus position 
was reached on practically all outstanding items. 
It is expected that a new, and hopefully final, 
balloting draft will be available in December with 
approval of the standard being targetted for early 
in 1992. 

POSIX.3.2 

POSIX.2 is the draft standard for shells and 
utilities, so it follows that POSIX.3.2 is the docu¬ 
ment containing related test methods. Most of the 
group concentrated on developing assertions for 
the remaining utilities with the aim of completing 
the majority of the document by the end of the 
meeting. Other parts of the group concentrated 
on reviewing work that had been done between 
meetings to align with recent drafts of posix.2. 

Some discussion took place on the manner in 
which grammars could and should be tested. This 
discussion was not entirely fruitful, with a decision 
to leave the depth of grammar testing to the test 
suite author. 

The group decided to formally conduct a re¬ 
view of the current test assertions, as it is believed 
that in many areas they are now relatively stable. 
While this was not considered to be a full mock 
ballot, it is expected to be a good preparatory 
stage towards that. The major items that remain 
outstanding are the application of Regular Ex¬ 
pressions to the utilities and test methods to cover 
the Internationalisation effects on each command. 

POSIX.4, POSIX.4a, POSIX.4b, POSIX.13: 
Real-time POSIX 

Bill O. Gallmeister <bog@lynx.com> re¬ 
ports on the October, 1991 meeting in Parsip- 
pany, NJ: 

Summary 

The posix.4 working group met for four days 
this session. We approved our first draft of the 
extended POSix. 4b Real-time Proposal, and held 
a useful mock ballot of our current draft of 
POSix. 13 (Real-time Profiles). Work on a real¬ 
time networking interface, in conjunction with 


POSix. 12 (Transport Layer Interfaces) continued. 
(They’re doing the work. We’re answering the 
questions when we can). POSix. 4 was very close 
to going out for ballot recirculation, and has since 
been recirculated. POSIX. 4a is still being readied 
for its recirculation. 

Real-time Application Profiles 

This week, we held a mini-mock ballot 
among the working group to get a feel for how 
close POSix. 13 is to being ready to ballot. POSIX.4 
has produced four different profiles, matching dif¬ 
ferent scales of real-time endeavor, [ed — These 
are described in earlier snitch reports.] One sig¬ 
nificant issue that must be addressed soon is the 
proposed subsetting of POSix.l that is required for 
the Embedded System application environment 
profile (AEP), the smallest real-time profile. This 
profile targets systems that may be unable to sup¬ 
port the fork system call, due to the lack of a 
memory management unit (MMU). We have pro¬ 
posed a subsetting of POSix.l that would allow a 
system without fork to claim conformance to this 
Embedded profile, i.e. it would claim conform¬ 
ance to posix. 13, not posix. l. 

Is it POSIX, or is it UNIX? 

The posix. l working group has responded to 
this proposed subsetting with a resounding “no”. 
In their opinion, posix. l is the minimal set of 
functions that an application should always be 
able to take for granted when the system claims 
POSIX conformance in any way, shape, or form. 
Any subsetting, it seems, amounts to a diminution 
of the POSIX ideal. This may be fine in the case 
of a workstation, mainframe, or even PC-class 
machine. In the case of embedded computing 
systems, this position amounts to a statement that 
posix has nothing to offer these systems, posix.4 
feels that this statement is wrong, and that we 
should take a pro-active stance in defining what 
posix conformance means when applied to such 
a small system, rather than letting this definition 
be done by the marketplace. 

The next step in this procedure is for posix.4 
to make a formal request for an extension to 
posix. l. Depending on posix. l’s response, we will 
proceed from there. Stay tuned for our next ex¬ 
citing episode! 
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POSIX.4b First Draft Readied 

POSIX. 4b, the proposal for further real-time 
extensions to posix. l, posix. 4, and posix. 4a, had 
its first few chapters approved, and a first draft of 
this material should be available soon. The ap¬ 
proved functions include a specification for spawn 
(a combined fork and exec which can be sup¬ 
ported on MMU-less machines), and a chapter 
specifying timed-out interfaces for blocking posix 
calls. 

Sockets 

The posix. 12 group continued its work on 
trying to accommodate real-time needs in the 
sockets facility. The issue du jour in Parsippany 
was whether select (or, alternatively, poll) pro¬ 
vided sufficient functionality for asynchronous 
message passing, or whether select should be mod¬ 
ified, or a new interface provided. The POSIX.4 
working group was unable to come up with a clear 
direction at this meeting, and we will be revisiting 
the issue at our next meeting in beautiful Irvine. 

Balloting Status 

Many of the technical reviewers for POSIX.4 
were present in Parsippany, and we were able to 
achieve the required 75% positive ballot response 
required for a recirculation, posix. 4 has now been 
recirculated, so the technical reviewers will have 
some gripping reading material for the Holidays. 
posix. 4a has been delayed a bit and has not yet 
gone to recirculation. As a matter of logistics, it 
is unlikely that posix. i3 will go to ballot until the 
recirculations of posix. 4 and posix. 4a become 
more routine. 

POSIX, 12: Protocol Independent Interfaces 

Tim Kirby <trk@cray.com> reports on the 
October 21-25 meeting in Parsippany, NJ: 

Summary 

The ongoing mission: two interfaces are pro¬ 
posed in language independent form —a Simple 
Network Interface (SNI) and a Detailed Network 
Interface (DNI). SNI is a proposal drawn from 
several sources with no (de-facto) standard. DNI 
is seen as a single language independent binding 
to which there are two valid C language bindings, 
sockets and XTI. 


The posix. 12 group took a hit this time in 
terms of attendance, with at least a couple of the 
members struggling to maintain funding/support 
for future attendance. One of these is the chair, 
Les Wibberley, who may not be around after the 
April meeting if he is unable to find funding to 
help with travel expenses to the tune of around 
US$3,000 per annum. If the funds are not found, 
we will be looking for a new chair to take over 
following the April meeting. Anyone who can 
either help or would be interested in the chair¬ 
manship of the group (corporate support is re¬ 
quired), please contact Les at the following ad¬ 
dress: 

Chemical Abstracts Service 
2540 Olentangy River Rd. 

Columbus, Ohio 43210 
<lhw25@cas.org>, <lhw25@cas.bitnet> 

Report 

This report will sound very similar to the 
previous (July meeting) report as discussion of 
many of the same issues continued from the pre¬ 
vious meeting cycle. 

Once again, liaison with other groups ab¬ 
sorbed a significant amount of the week. These 
groups were posix .4 (Real-time), posix. 11 
(Transaction Processing), and posix. 17 (Direc¬ 
tory Services). It has been proposed that POSIX. 12 
will encompass all the functionality required by 
POSIX.4 and POSIX.11. After careful study, the 
group’s consensus was that one or two of the 
requirements would be well placed in the posix. 12 
standard, but those remaining (the majority) 
should be implemented above the posix. 12 inter¬ 
face level. The scope of our project will be ex¬ 
amined to ensure that any proposed standard is 
consistent with that scope. 

The posix. 17 (Directory Services) liaison 
meeting was productive and resulted in several 
action items to be worked on before the next cycle 
to synchronize the two interfaces. 

Multicast support, as required for lightweight 
stacks such as XTP, is also receiving careful at¬ 
tention to ensure the proposed interface standards 
will support such functionality. 

The long outstanding issue of the inadequa¬ 
cies of the listio( ) functions with regard to 
the networking interfaces was brought to some 
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resolution. There is a requirement for some form 
ofselect() orpoll() functionality that does 
not appear anywhere in the current posix inter¬ 
face arena. The Systems Interface Coordination 
Committee (SICC ... also known as the Steering 
Committee on Systems Interfaces, or SCSI) 
worked on this item, eventually passing it to the 
posix. l working group. There’s an action on 
POSIX. 12 to provide a detailed specification of the 
requirement. SICC is a newly formed ad hoc com¬ 
mittee of the base interface group chairs, whose 
function is to address some of the immediate co¬ 
ordination concerns between groups. 

Other items worked on during the week were 
the glossary for the posix. 12 standard, test as¬ 
sertions, and detailed discussions on the genera¬ 
tion of Language Independent specifications for 
both DNI and SNI. 

A significant number of actions were assigned 
for between-cycle homework in most of the areas 
mentioned. The current plan for posix. 12 has a 
mock ballot sometime in the second quarter of 
1992, with a real ballot following around the 
fourth quarter. Given the additional work items 
picked up from posix. 4, posix.11, and the Mul¬ 
ticast extensions, there is some project reviewing 
and possibly some reworking of proposed dates to 
come. Any additional support is most welcome 
from willing volunteers! 

Report on POSIX. 17 - Directory Services API 

Mark Hazzard <markh@rsvl.Unisys.com> 
reports on the October 21-25, 1991 meeting in 
Parsippany, New Jersey: 

Summary 

As promised, Draft 2.0 of posix. 17 (Direc¬ 
tory Services API) went to Mock Ballot before 
the Parsippany meeting. The group made solid 
progress processing input from the Mock Ballot. 
We also identified work items and began planning 
for an official IEEE ballot which is slated for 2nd 
quarter 1992. Significant work remains in the area 
of test assertions and general document format¬ 
ting. 

Introduction 

The posix. 17 group is generating a user to 
directory API (e.g., an API to an X.500 Directory 


User Agent). We are using XAPIA — X/Open’s 
Directory Services specification (XDS) as a basis 
for work. XDS is an object oriented interface and 
requires a companion document, X/Open’s Ob¬ 
ject Management specification (XOM) for object 
management. 

XOM is a stand-alone specification with gen¬ 
eral applicability beyond the API to directory 
services. It will also be used by IEEE P1224.1 
(X.400 API), and possibly other POSIX groups, 
and is being standardized by P1224. 

Status 

Only four of the six “core” working group 
members who attended the Santa Clara meeting 
showed up in Parsippany. Despite assurances 
from the missing members to be there next time, 
participation remains an issue. Due to the small 
number of committee members, there’s a lot of 
work for everybody, especially in the next 3-4 
months as we get ready for ieee Ballot. Ours was 
one of several groups hit by the lingering reces¬ 
sion. I guess standards need to be completed dur¬ 
ing prosperous years. 

The Mock Ballot of posix. 17 Draft 2.0 was 
completed between meeting cycles with com¬ 
ments received from less than 10% of the ballot 
group. We spent most of the meeting processing 
those comments. 

Significant editorial changes will be required 
to resolve the comments, including separating and 
clearly labeling normative vs. non-normative text, 
adopting a stricter, more legalistic nomenclature 
and style for the normative sections and generally 
tightening up the draft. Several technical changes 
were suggested and these will be processed be¬ 
tween meetings. 

The Technical Editor accepted an action to 
complete the Language Independent Specifica¬ 
tion (LIS) and test assertions by the next meeting. 
Our plan is to complete outstanding work items 
and begin IEEE Ballot on April 1, 1992 with a 
complete draft. 

Once again, we met with posix. 12 (Protocol 
Independent Interfaces) in joint session and dis¬ 
cussed their requirements for directory services. 
The posix. 12 group produced an updated version 
of their directory requirements paper which was 
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briefly discussed. We also addressed Mock Ballot 
comments submitted by the POSIX.12 chair, which 
by and large reflected the concerns of his group. 

There was general agreement that the 
POSix.17 API provided sufficient functionality 
and, in any case, POSIX.12 would be using only a 
small subset of the functions (primarily read and 
search). The main issues seem to be the com¬ 
plexity of the API, how the directory information 
tree (DIT) gets extended and the mechanics of 
how new (posix.12 required) objects get defined. 

It was agreed that we would continue to re¬ 
fine the posix.12 requirements, using their white 
paper as a basis. We decided that a “small” group 
consisting of members of posix.12 and posix.17 
should meet regularly to resolve outstanding is¬ 
sues. 

POSIX.17 and P1224 met again in joint session 
to continue to review/revise the XOM specifica¬ 
tion. Many corrections were made, and a new 
draft will be released before the next meeting. 
P1224 is scheduled to go to ieee Ballot in the first 
quarter of 1992. Since P1224 is a normative ref¬ 
erence for POSIX.17, a stable version is essential 
for our ballot. 

The group met with a consulting member of 
posix.3 (Test Methods) to review our test asser¬ 
tions to date. The feedback we received was pos¬ 
itive from the perspective that, if anything, we 
had gone overboard on writing assertions, and 
that less effort than planned would be required to 
complete them. We were also informed that 
X/Open had agreed to fund our technical editor 
to write the assertions for POSIX.17. 

The posix.O group (posix Guide) held a re¬ 
view of the “networking” sections of their latest 
draft (D13). All the distributed services groups 
attended and expressed their concerns, some 
claiming that their input to posix.O had been 
largely ignored. It was noted that the posix.O 
model is seriously flawed in that it doesn’t account 
for systems integrators and recognize their needs. 
This message was acknowledged and will hope¬ 
fully be accommodated in subsequent versions of 
the posix.O draft. 

In Closing , . * 

There are quite a few homework assignments 
between meetings, including forming the ballot 


group, rewriting/reformatting sections of the spec¬ 
ification and responding formally to our Mock 
Ballot comments. 

The group will reconvene January 13-17, 
1992 at the ieee posix meeting in Irvine, CA. 

ANSI X3B11.1: WORM File Systems 

Andrew Hume <andrew@research.att.com> re¬ 
ports on the October 21-25,1991 meeting in Mer¬ 
rimack, New Hampshire and on the TCl5 meet¬ 
ing on November 11-15, 1991 in Geneva, 
Switzerland. 

Introduction 

X3B11.1 is working on a standard for file in¬ 
terchange on random access optical media: a por¬ 
table file system for worms or rewritable optical 
disks. TC15 is a committee within ecma that works 
on file system standards. This report covers the 
last X3B11.1 meeting in Merrimack, New Hamp¬ 
shire and the last TC15 meeting in Geneva, Swit¬ 
zerland. The report describes the cumulative ef¬ 
fects of both meetings, mainly as a set of changes. 
In brief, we are conducting a letter ballot on 
whether to forward the current draft on for pro¬ 
cessing as an ANSI standard, and simultaneously, 
the draft is undergoing editing for processing as 
an ecma and eventually, as an iso standard. 

The Current Draft Working Paper 

The draft is now essentially three distinct 
standards, more or less, embedded within a single 
document. 

The first standard describes a generic 
scheme, upward compatible with iso 9660, for 
recognising boot records, and which standard de¬ 
scribes how the volume has been recorded. This 
allows media to be recorded with boot blocks for 
several different system architectures and differ¬ 
ent operatings systems. The goal is that a generic 
boot ROM could search for all the boot blocks for 
the current system, somehow ask the user for 
which one to use, and then load a boot block into 
memory and execute it. 

The second standard is a volume structure 
standard. It provides mechanisms for labelling 
volumes and volume sets, managing unallocated 
space on a volume basis, describing partitions and 
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a label of the partition’s contents, and an optional 
scheme for bad sector management. 

The third standard is a file system structure, 
corresponding fairly closely to a UNIX file system 
augmented by symbolic links and extended at¬ 
tributes. 

Boot/Volume Recognition 

This part was negotiated at the TC15 meeting 
and is identical with the corresponding part of the 
cdwo draft. In case you don’t know what cdwo 
is, it is a worm disk based on the CDROM tech¬ 
nology. Under certain recording modes, a cdwo 
disk can be read on CDROM drives. On the 
whole, it seems a painful device to program for, 
but the dream is that the CDWO drives can be 
made quite cheaply and they can be used for 
reading ISO9660 disks and writing cdwo disks 
(say, for backup). The cdwo folks are also known 
as the Frankfurt group. (Why are standards 
groups known after the city where they first 
meet?) 

The TC15 proposal says basically, at sector 16 
there is an optional sequence of ISO9660 descrip¬ 
tors terminated by the ISO9660 terminator descrip¬ 
tor. Then follows an arbitrary (including zero) 
number of extended descriptor sequences, each 
begun and terminated with specific descriptors. 
The contents of these sequences are either generic 
boot descriptors (common amongst standards) or 
standard-specific descriptors. We defined one 
such descriptor; it simply points to our normal 
structures. The boot descriptors may well be the 
most useful part of this standard, particularly if 
vendors adopt it. The boot descriptors are quite 
flexible. They describe an extent of sectors on the 
media. They contain: 

• a 32 byte architecture identifier, 

• a 32 byte operating system identifier, 

• a 64 bit load address for the extent and 

• a 64 bit start address. 

Volume/Partition Structure 

This part is largely unchanged since my last 
report. We added a new kind of partition, a cat¬ 
enation of other partitions, in order to support 
hybrid media which is a mixture of different me¬ 
dia types, say read only and rewritable. The other 
changes mainly have to do with simplifying things 


for smaller implementations, such as on memory- 
limited PCs. A new level of interchange has been 
added for low end implementations with some 
simplifying restrictions on recording volume de¬ 
scriptors (for example, a single extent at a fixed 
location). 

File System 

This part has changed in a lot of small details, 
mainly for harmonization with the cdwo draft. In 
a valiant attempt to reduce the number of regis¬ 
tration authorities, we dropped a bunch of some¬ 
what dubious extended attributes and systema¬ 
tised a general approach for registerable 
properties, such as file system type or extended 
attribute type. In general, these are 32 bit num¬ 
bers and some authority, such as ecma or ANSI, 
manages a registry mapping numbers to textual 
descriptions. Our registration type is a 32 bit num¬ 
ber and a 32 byte field. (It happens that often you 
need some data to go with the registration num¬ 
ber). Furthermore, a number of zero means that 
there is no official meaning but that the 32 byte 
field may specify the meaning in an imple¬ 
mentation-defined way. This allows folks to im¬ 
plement and experiment before going through the 
bother of registering. 

International Activity 

The TC15 meeting was surprisingly effective 
and we made many useful changes. It was par¬ 
ticularly rewarding (for me) to finally meet with 
the representative from Fujitsu, which has been 
quite active and vocal (and constructive) with its 
comments on our draft. 

There is much emphasis on producing stan¬ 
dards in a timely fashion within TC15. The current 
schedule, for both our draft and the cdwo draft, 
is that all technical details be fixed by the January 
meeting and that the January and March meetings 
be editorial in nature. We hope/expect that the 
drafts will be voted on and adopted as ecma 
standards at the June 1992 ecma General As¬ 
sembly meeting. They then would start on the iso 
“fast track” process and assuming no negative 
votes at the iso level, would become an iso stan¬ 
dard around March or April 1993. (This is about 
6 to 8 months before the draft could become an 
ANSI standard, assuming best case for the ANSI 
process.) 


26 


January/February 1992 



;login: 17:1 


Because of TCl5’s preoccupation with its two 
drafts, work on the general storage architecture 
model has been postponed. 

Electronic Distribution of Standards/ 
Drafts 

Since I became technical editor of X3BH.1, 
my drafts have been available electronically by 
both ftp and email {netlib) from research 
• att.com. (For ftp, login as netlib.) For details, 
get index from research/memo. 

This has been extended to various ieee stan¬ 
dards as an experiment with the permission and 
blessing of the ieee Standards Board, resources 
provided by AT&T, and with the cooperation of 
the various editors involved, most notably Hal 
Jespersen. Currently, these include drafts, meet¬ 
ing notices and meetings for the posix committees 
P1003.2, P1003.2b, P1003.0 and ieee 896 (Fu- 
turebus + ). Drafts are available in PostScript or 
ASCII, compressed or not, and as page bundles 
(pages 101-120) or discrete sections (3.4.2). (For 
further details, get index from posix and/or 
base.) This has proven to be very popular; with¬ 
out wide advertising there have been over 7000 
requests for posix stuff in the first two months. 

Other happenings 

The ieee is starting up a new committee on 
Hypermedia and related topics. One of the initial 
project requests (PARs) for this committee is 
(more or less) making the Rock Ridge proposal 
a standard. This strikes me as puzzling but I hope 
to find out why when they start having meetings. 

The Rock Ridge proposal is an attempt to 
make the CD ROM standard, ISO9660, which is by 
and large designed for use on VMS and MS-DOS, 
useful for recording UNIX file systems. It does so 
by recording the stuff ISO9660 left out in certain 
implementation use areas. I am yet unclear why 
this should be an ieee standard when the cdwo 
draft provides a strict superset of the Rock Ridge 
functionality and the CDWO will probably be an 
ecma standard. It maybe will even be a ISO stan¬ 
dard before the Rock Ridge proposal could be¬ 
come an IEEE standard. (To say nothing of the 
apparent stupidity in having two standards, one of 
which is a subset of the other.) 

Admittedly, there is a fine distinction be¬ 
tween the two proposals. The Rock Ridge format 


is pure ISO9660; implementations just have to be 
changed to recognise and act on certain imple¬ 
mentation use descriptors. The cdwo proposal 
adds new descriptors in an area just after where 
ISO9660 stops looking for descriptors — imple¬ 
mentations have to be changed to look further 
for, and recognise, these new descriptors. I, and 
I suspect most users, think this distinction is pretty 
much meaningless; both proposals can be read (at 
least the ISO9660 information) by ISO9660 systems, 
and ISO9660 disks can be read. 

The difference in implementation effort for 
either proposal seems small, particularly when 
you consider most of the work goes into the file 
system and kernel interface code. The two 
groups, Rock Ridge and Frankfurt, have agreed 
that their work occupies different niches and 
therefore justifies two separate standards, al¬ 
though I suspect this is a post-hoc rationalisation 
more to do with marketing and economic reasons 
rather than technical or user-related reasons. 
With any luck, the committee may decide that the 
Rock Ridge needs are sufficently met by the 
cdwo proposal. 

At COMDEX, IBM made it known that it 
will be announcing the general release of an op¬ 
tical product in late 1991 or very early 1992 and 
this would include a volume and file system for¬ 
mat. (This has been in field test for some time 
now.) I regret that although IBM was represented 
at the first few X3BU.1 meetings, they stopped 
coming and the IBM format is unrelated to, and 
uncoordinated with, the X3B11.1 draft. 

Finale 

It seems likely that something very close to 
the current draft will become an iso standard for 
(essentially all) random access media. Even if you 
don’t care about the file system aspect, you may 
(should?) be interested in the proposed booting 
and volume recognition scheme. It would be quite 
worthwhile for there to exist a generic way to boot 
off media, but it will only happen if it is useful and 
meets most vendor’s needs. I would be very in¬ 
terested in feedback on this aspect of the draft. 

If you wish to comment on the draft, get a 
copy electronically, or contact me or the X3B11.1 
chair (Ed Beshore) for a copy. If you work for a 
company represented on the committee, com- 
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ments ought to be tunneled through that repre¬ 
sentative, but in any case, I will collect and 
present any comments sent to me. Comments 
would need to be received by me prior to De¬ 
cember 27, 1991. 

If you would like more details on x3Bill’s 
work, you should contact either me 
(andrewSresearch.att.com, 908-582- 
6262) or the committee chair, Ed Beshore 
(edbShpgrla.hp.com, 303-350-4826). The 
critical document is the current draft of the work¬ 
ing paper (about 80 pages). There is also a pro¬ 
grammer’s guide to the draft (about 18 pages 
written by me). I will send you copies of the latter 
document; requests for other documents or more 
general inquiries about x3Blll’s work would be 
best sent to Ed Beshore. 

The next meeting is in Santa Clara, CA on 
January 6-10, 1992 and will address the ballots 
from the letter ballot. Anyone interested in at¬ 
tending should contact either me or Ed Beshore. 

Report on X3J16: C++ 

Mike Vilot <mjv@objects.mv.com> reports 
on the November, 1991 meeting in Dallas, Texas: 

Current Status 

The ansi x3H6 / iso wg21 committee con¬ 
tinued refining some of the important conceptual 
details of the C++ language. During this meeting, 
the committee made decisions on issues that had 
been discussed since the March meeting in 
Nashua, including name lookup semantics and 
translation limits. 

November meeting 

Texas Instruments hosted the meeting in Dal¬ 
las. The week’s major activities focused on the 
informal working group meetings. Many members 
had been unable to attend the June meeting in 
Sweden, so much of the effort went into regaining 
momentum lost since the March meeting. 

The x3j16’s sub-groups focus was on the key 
topics listed in the goals statement developed at 
the March, 1990 meeting. They worked by elec¬ 
tronic mail between meetings, and reported their 
progress. 


International Concerns 

Steve Carter, of Bellcore, presented the ma¬ 
jor international concerns. Steve is the Convener 
of iso wg21 

During the summer, X3J16 conducted a letter 
ballot and voted in favor of converting to a Type 
I standards project. Steve reported that the nec¬ 
essary administrative matters to coordinate the 
work of X3J16 and wg21 had been completed. 

He also relayed the requests of SC 22 (wg21’s 
parent organization) to consider certain topics 
important to the international community: 

• support for international character han¬ 
dling 

• support for language independent data 
types and arithmetic operations 

• a portability annex in the eventual standard 

Editorial 

Jonathan Shopiro, of at&t, presented the 
Editorial group’s work. 

Much of the recent work on the document 
has been in clarifying or defining basic terms. The 
process of resolving the definitions of the two base 
documents continues. (These are the Annotated 
C++ Reference Manual (ARM) and the C stan¬ 
dard.) For example, the C standard uses the term 
“compatible type”, while the ARM uses the 
phrase “the same type”. The editorial changes 
involve using one term or the other consistently 
throughout the document. 

One minor change clarified that enumera¬ 
tions are distinct types, even though enumeration 
values still promote to int. 

Formal Syntax 

Jim Roskind, of Roskind Software, pre¬ 
sented the work of the Formal Syntax group. 

The group revisited issues it had raised at the 
March meeting, regarding changes to the delim¬ 
iters used for template argument lists, and minor 
changes to the grammar involving throw- 
expressions. 

The discussion on replacing the ’<’ and ’>’ 
delimiters in the template syntax (in favor of ’(’ 
and ’)’ or some other pair of “matching” tokens) 
uncovered no new issues. Document 91-0033 pre- 
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sents the full discussion of this issue. Since the 
parsing difficulties could be addressed with a 
slightly more complex grammar, and no alterna¬ 
tive pair of tokens was clearly preferable, the final 
vote was to lay the issue to rest with no change 
in the syntax. 

The discussion of the grammar involving 
throw-expressions resulted in a minor change to 
the language. Documents 91-0013, 91-0034, and 
91-0048 discuss the details. 

One other minor change involved the word¬ 
ing of the description of template type arguments. 
Document 91-0061 describes the issue. 

Core Language 

Andy Koenig, of at&t, presented the Core 
Language group’s work. 

Most of the Core Language discussion cen¬ 
tered on name resolution issues. These issues are 
highlighted by the interactions of nested classes, 
inline friend function definitions, and static class 
members. 

After much discussion (some of it heated), 
the group arrived at what they felt was an ac¬ 
ceptable specification of name lookup semantics. 
A brief description of the proposed rule is that the 
scope of a name declared in a class consists not 
only of the text following the name’s declarator 
(to the end of the class), but also all of the func¬ 
tion bodies and constructor intializer in the class. 

The Core group will have a precise descrip¬ 
tion in writing for the next meeting. 

Another issue the group addressed (but did 
not resolve) was the specification of the lifetime 
of implementation-generated temporary objects. 
At the March meeting, the group had considered 
the effects of early (end of expression) and late 
(end of enclosing block) destruction of such tem¬ 
poraries. Consensus seems to be forming on a 
middle ground, but requires a precise definition of 
its semantics. 

Bjarne Stroustrup pointed out that the 
emerging position is roughly that ‘temporaries 
persist to the end of the enclosing basic block.” 
The group still has to resolve some details, be¬ 
cause the proposed semantics do not exactly 
match the usual definition of basic blocks. 


Environment 

Peter Chapin, of Vermont Technical College, 
presented the work of the Environment group. 

The major topic of discussion was on what 
translation limits the eventual standard should 
define. Although there were some very strong 
arguments against specifying limits (the strongest 
being that such numbers turn out to be upper 
limits in too many “conforming” implementa¬ 
tions), the committee decided in favor of speci¬ 
fying such limits. The environment group will 
propose specific limits at the next meeting. 

The group also continued refining the se¬ 
mantics of static object initialization. Their cur¬ 
rent proposal is to introduce two types of trans¬ 
lation units, to distinguish between objects in 
dynamic link libraries and objects that can be 
initialized before entering the main ( ) function. 

Libraries 

I presented the Library group’s work. 

The most important result of the week was to 
scrap the existing proposal for string classes (doc¬ 
ument 91-0078) and start over. Uwe Steinmueller 
of Siemens-Nixdorf contributed his experience in 
implementing string classes to the effort. The 
group will have a new proposal for the next meet¬ 
ing. 

Work progressed on standard exceptions, 
based on Jerry Schwarz’s proposal (document 
91-0116). The group proposed changing the de¬ 
fault behavior of the newhandler to throw an 
xalloc exception. 

We refined the iostreams proposal (docu¬ 
ment 91-0117). The group discussed several mi¬ 
nor issues in the proposal: 

• national character set streams 

• file open modes 

• wide character support 

• interaction with other standards (e.g. 
ASN.l) 

• names of header files 

• specification of streampos, 

streamoff “types” 

• exceptions thrown by streambuf 

• specification of mode flag “types” 

Notably, most of the issues involved acco¬ 
modating International Concerns over character 
handling. The group will have a revised proposal 
at the next meeting. 
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The new item for the Library group involved 
proposals for standard “container” classes. Based 
on Chuck Allison’s survey of existing libraries 
(document 91-0111), the group found a half- 
dozen abstractions recurring in each library (vec¬ 
tor, list, queue, stack, bitset, hash table). 

The basic design approach for these con¬ 
tainer classes will be template classes specifying 
concrete data types. That is, no elaborate 
Smalltalk-like Collection hierarchy, ultimately 
rooted at class Object. Members of the group with 
experience implementing the “easy” classes vol¬ 
unteered to write up proposals for the next meet¬ 
ing (specifically, bitset and vector). 

The Library group will also investigate lan¬ 
guage independent data types, and arithmetic op¬ 
erations. For example, a standard class complex 
could be included in the library, rather than re¬ 
quiring a new built in data type. 

Language Extensions 

Bjarne Stroustrup, of at&t , presented the 
work of the Extensions group. 

The group proposed an explicit procedure for 
considering and deliberating on submitted exten¬ 
sions. A recent series of postings to comp- 
. lang*c++ by Jim Adcock of Microsoft indi¬ 
cated his dissatisfaction with the “openness” of 
x3j16’s work. Sensitive to the experience of the C 
committee (where a J. Hansberry invoked the 
formal procedures of ANSI to delay the publi¬ 
cation of that standard by over a year), the Ex¬ 
tensions group is going out of its way to give an 
unbiased hearing of every proposal submitted. 

The group is working through a long list of 
proposals for changes to the language. Some of 
the items are: 

• support for run-time type information 

• adding 8-bit (i.e., international) characters 
in identifiers 

• allowing virtual functions in a derived class 
to use a more specific return type than the 
base class version of the function 

• allowing overloading of the dot operator 

• a name space control mechanism 

• keyword parameters (like Ada’s) 

• programmer-defined operators new and de¬ 
lete for arrays 

■ new keyword const 

• constrained genericity in template type ar¬ 
guments 


• extensions to control the order of static 
object initialization 

Every proposal will have at least one person 
(not the original author) examine the proposal 
and investigate its impacts on the existing lan¬ 
guage. Once the working group has reached a 
consensus on whether to recommend accepting or 
rejecting the proposal, it will bring the issue to the 
full x3j16 for a discussion and formal vote. 

The group is working on a written guide to 
preparing language extension proposals, to en¬ 
courage proposals which are complete enough to 
receive an adequate discussion. 

C Compatibility 

Tom Plum, of Plum-Hall, presented the work 
of the C Compatibility group. 

The group continued its investigation of the 
vocabulary differences between C and C++ . Only 
a few of the differences have been resolved, and 
Tom plans to meet with Jon Shopiro to decide 
which terms can be incorporated as C++ defini¬ 
tions. 

Next events 

The next three X3J16 meetings (and their 
hosts) will be: 

• March 16-20 1992, London, UK (BSI and 
Zortech/Symantec) 

• July 12-17 Toronto Canada (IBM) 

• November 8-13, Boston MA (OSF) 

Membership on an x3 committee is open to 
any individual or organization with expertise and 
material interest in the topic addressed by the 
committee. The cost for voting or observer mem¬ 
bership is $250. Contact the chair or vice chair for 
details. 

Chair: Dmitry Lenkov 

HP California Language Lab 

19447 Pruneridge Avenue MS 47 le 

Cupertino, CA 95014 

(408)447-5279 

fax (408)447-4924 

email dmitry@cup.hp.com 

Vice Chair: Stephen D. damage 

TauMetric Corporation 

8765 Fletcher Pkwy, Suite 301 

La Mesa, CA 91942 

(619)697-7607 

fax (619)697-1140 

email steve@taumet.com 
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Book Reviews 

3:16 Bible Texts Illuminated 

by Donald E. Knuth 

(A-R Editions, Inc., Madison, Wisconsin, 1991, ISBN 0-89579-252-4, 268 pages, $29.95) 

Reviewed by Barry Shein 
Software Tool & Die 


This is a rather odd book to review for this 
periodical. So why is it here? Donald Knuth, 
Professor of Computer Science, Stanford Univer¬ 
sity, author of the three volume Art of Computer 
Programming (perhaps someday to grow to seven 
volumes), TeX, MetaFont and many other tracts 
on Computer Science and Mathematics over the 
past few decades is a seminal figure in Computer 
Science. Consequently, this book piqued my in¬ 
terest. 

The premise of 3:16 Bible Texts Illuminated 
is to take Chapter 3, Verse 16 from every book 
in the Bible (Old and New Testament) and reflect 
on their contents in turn. Knuth describes this as 
a stratified sampling approach. His intent is to 
take the reader on a “grand tour” of the Bible, 
both Old and New Testaments. The choice of 3:16 
is not random, the author is personally impressed 
with John 3:16 (“Yes, God loved the world so 
much that he gave his only child, so that all people 
with faith in him can escape destruction and live 
forever.”) There are a few books which do not 
have a Chapter 3; these are omitted entirely. 
There are a few books which have a Chapter 3 but 
do not have a verse 16. These are included, but 
the verse studied is the 16th verse after the start 
of Chapter 3 (e.g., Jonah 4:6). 

The book is organized into 59 chapters, one 
per verse. Each chapter begins with a one page 
overview of the chapter and its place in the bible 
and a calligraphic illustration of the verse on the 
facing page. The illustrations were done by many 


different artists and are well done throughout. 
The next two pages of the chapter explores the 
verse itself. Every chapter is organized in pre¬ 
cisely the same way, four pages. 

Knuth’s book is very readable, perhaps one 
of the most readable books I have picked up in 
years. There is something about a book organized 
into short, interesting bites that has always ap¬ 
pealed to me. Perhaps that is why I spent far too 
much of my childhood reading an encyclopedia. 
This is also a very pretty book, and would make 
a fine gift for anyone who might be interested in 
its content. 

Personally, I was raised in an intensely reli¬ 
gious (orthodox Jewish) environment, and find 
sections of his commentary which I take exception 
to or wish that he had asked a few more scholars 
about before presenting his interpretation. Knuth 
has used extensive resources to prepare this book, 
but many comments seem parochially middle- 
American in their interpretation, a bit literal for 
my tastes. Much of the potential spirituality and 
mysticism is ignored even as a possible interpre¬ 
tation (to his credit, the author is not shy about 
mentioning commentary he does not personally 
subscribe to). However, this is a minor criticism, 
and the sort that has been made on every Bible 
commentary ever written over the past few thou¬ 
sand years. Why should I sever that age-old tra¬ 
dition in this review? “Meanwhile, let us keep in 
step with the pace we have set” (Philippians 3:16). 
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Illustrating Computer Documentation: The Art of Presenting Information 
Graphically on Paper and Online 

by William Horton 

(John Wiley & Sons, 1991, ISBN 0-471-53845-0, 313 pages, $32.95) 

Reviewed by Barry Shein 
Software Tool & Die 


I have mixed feelings about Horton’s book, 
Illustrating Computer Documentation . I know it 
will be useful to someone but I can’t quite put my 
finger on who that might be. Certainly one group 
that might benefit from owning this book would 
be small departments and companies who occa¬ 
sionally need to produce documentation, but can’t 
always afford to have full-time graphics designers 
helping them. This would be particularly true if 
the people charged with the documentation have 
a tendency to be a bit grapho-phobic, unsure 
whether decisions they are making about presen¬ 
tations are conventional and whether serious 
gaffes are being avoided. 

The title of the book is a little misleading. 
Although the author does touch upon the topic of 
online presentation, it is focused on only briefly, 
except inasmuch as the graphical principles he 
presents throughout the book would be applicable 
to any graphics problem. Even his brief treatment 
of the topic indicates that there really are special 
considerations for online presentations, such as 
low resolution jaggies and screen clutter. 

Horton’s book is strongest where it talks 
about conventions in graphical presentation, such 
as internationalization issues (a hand making a 
circle with thumb and forefinger is obscene in 
some countries, while in others it indicates 


“OK”). He also spends some pages categorizing 
various graphic displays such as onion charts and 
fence diagrams. Had he gone through these cat¬ 
egories more methodically and exhaustively (per¬ 
haps even including an appendix of examples and 
glossary of terms) the book could have been a 
great reference work. If there is a second edition 
I would urge him to consider providing this ser¬ 
vice. 

The book is weakest when the author is 
overly prescriptive. For example, he urges the 
reader to be egalitarian and androgynous when 
designing illustrations involving more than one 
person. Well, that’s fine, except when your mes¬ 
sage purposely means to express hierarchy or het¬ 
erogeneity. The solution to society’s ills is prob¬ 
ably not homogenization in graphics, although 
admittedly it is a source of never-ending offen¬ 
siveness where inappropriate. Perhaps that was 
his point, but it was made too strongly. 

Illustrating Computer Documentation is 
worth a look, particularly if you do not design 
graphical presentations professionally. It might 
also be a good source book for educators who 
wish to touch upon computer presentation topics 
within the scope of a general graphics design 
course. 
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USENIX Board of Directors’ Meeting 


Below is a summary of the actions taken at 
the regular quarterly meeting of the usenix 
Board of Directors held at Berkeley, CA, on Oct. 
12, 1991. 

Attendance: Rick Adams, Ed Gould, Rob Kol- 
stad, Kirk McKusick, Sharon Murrel, Evi Nem¬ 
eth, Mike O’Dell, Barry Shein, Ellie Young, 
Doug Nielson, Judy DesHarnais, Eric Allman 

1991 Budget 

Young remarked that the estimated year-end 
deficit was a lot less than previously projected. 
The exhibit manager’s efforts in keeping the 
Nashville exhibition costs down, and the high en¬ 
rollment at the LISA Conference were significant 
factors in helping to reduce the deficit. 

1992 Preliminary Budget 

McKusick felt that we should postpone dis¬ 
cussion on ways to reduce the projected deficit 
until attendance figures for the Winter ’92 con¬ 
ference and estimates for events next Fall are 
known. It was decided that the organization 
should budget to increase the reserve by $150,000 
a year for each of the next 5 years. 

Funding & Fee Proposals 

Standards Institutional Representative and 
Snitch Editor. It was decided to accept Peter Col- 
linson’s proposals for funding IR and Snitch Ed¬ 
itor activities in 1992. 

ISO Monitor Representative. McKusick ex¬ 
plained that Dominic Dunlop would be stepping 
down from this position at the end of the year. 
EurOpen would like to continue with the joint 
appointment and had completed a candidate 
search. It was decided that collaborative efforts 
were made, and that EurOpen did due diligence 
in finding a replacement for Dunlop. Stephe Wal¬ 
k’s application to be the ISO WG15 Monitor rep¬ 
resentative for USENix/EurOpen was accepted. 

Membership Dues and Conference Fees. It 
was agreed that we set dues at: Individual: $65; 


Student $20; Supporting: $1,000; Educational: 
$165; Corporate: $300; and that conference reg¬ 
istration fees be raised to $255 for members and 
$320 for non-members. 

Conference Revenue Protection Insurance. 
It was agreed that the Association regularly pur¬ 
chase conference revenue insurance. 

UUNET 

Adams reported that uunet had paid off the 
last of its loan from usenix and there were no 
fiduciary or legal ties. 

World Forum 

It was decided that while the proposal from 
UniForum for USENIX to join the World Forum 
group was an interesting concept, that a more 
substantive proposal is needed before a decision 
can be made. 

Winter ’92 Conference 

Allman reported that things were going well. 
The program committee had received 104 sub¬ 
missions, of which 35 were accepted. He spent a 
lot of time editing the feedback to authors. 

Summer ’92 Conference 

Adams reported on his program committee, 
and said he had tried to have people who had not 
previously served. He stressed the need for stron¬ 
ger coordination of the tutorials, invited talks, 
and refereed programs. A proposal to have some 
participation by vendors at this conference was 
accepted. 

LISA ’91 Conference 

A written report from Elizabeth Zwicky was 
discussed. Kolstad reported that the attendance 
had been extraordinary (513 total, with 197 from 
California), and the unique tutorial offering with 
7 instructors had been well-received. The pro¬ 
gram committee had put in a lot of work and were 
instrumental in making the conference successful. 
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Proposals to Chair LISA ’92 Conference 

From the five proposals received, it was de¬ 
cided to accept the one from Trent Hein with 
some modifications, and that he chair the 1992 
LISA conference. 


Proposal to Chair UNIX Security Symposium 

It was decided to accept the proposal from 
Edward DeHart that usenix sponsor a UNIX Se¬ 
curity Symposium in cooperation with CERT in 
the Fall of 1992. 


Proposal to Chair File Systems Workshop 

The proposal from Peter Honeyman to spon¬ 
sor a File Systems Workshop in Ann Arbor in 
May 1992 was accepted. 


Errata: 

How to Spell Sh[ao]piro or Confusion 

There are two people with very similar names 
who work on C++. One of them is Jonathan 
S. Shapiro, the author of “A C++ Toolkit,” and 
the other is Jonathan E. Shopiro, the Chairman 
of the 1992 usenix C++ Technical Conference 
and Editor of the ANSI/ISO C++ Standard. 
Needless to say, the similarlity in names causes 
some confusion. 


Other Business 

It was decided to seek an institutional mem¬ 
bership exchange with the nascent Internet Soci¬ 
ety. Adams proposed putting one rack of IP 
equipment in the usenix executive office, thereby 
providing usenix with a more reliable and free 
Internet connection. The Board was favorable to 
this suggestion as it represented the continuing 
cooperative spirit between uunet and usenix. 

Next Meeting 

It was decided that the first day of the regular 
Board of Directors meeting be held on Sunday, 
January 19 in San Francisco, California, and if a 
second day is needed it would be scheduled on 
January 20. The Open Meeting with the Board of 
Directors and Candidates Forum will be sched¬ 
uled on Tuesday, January 21 from 8:00-10:00 
p.m. at the Hilton Hotel. 


Times Three 


In the November/December 1991 issue of 
;login: we published a review of “A C++ Tool¬ 
kit” by Jonathan S. Shapiro and misspelled his 
last name. 

Apologies to both parties, Sirs Shapiro and 
Shopiro! 
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l $ 

20 

$ 

Denver 

Winter '86 

25 

25 

$ 

15 

$ 

Portland 

Summer '85 

45 

45 

1 $ 

25 

$ . 

Dallas 

Winter '85 

15 

15 

$ 

10 

$ 

Salt Lake City 

Summer '84 

29 

29 

1 $ 

20 

$ 

Washington, DC 

Winter '84 

25 

25 

$ 

15 

$ 

Toronto 

Summer '83 

32 

32 

$ 

20 

$ 

San Diego 

Winter ’83 

28 

28 

$ 

15 

$ 

LARGE INSTALLATION SYSTEMS ADMINISTRATION 






LISA V 

Sept. '91 

20 

23 

£ 

11 

$ 

LISA IV 

Oct. '90 

15 

18 

$ 

__ 8 

$ 

LISA III 

Sept. '89 

13 

13 

S 

_ 9 

$ 

LISA II 

Nov. '88 

8 

8 

$ 

5 

$ 

LISA I 

April '87 

4 

4 

$ 

5 

$ 

C++ 







C++ Conference 

Apr. '91 

22 

26 

$ 

_ 11 

$ 

C++ Conference 

Apr. '90 

28 

28 

S 

18 

$ 

C++ Conference 

Oct. '88 

30 

30 

$ 

20 

$ 

C++ Workshop 

Nov. ‘87 

30 

30 

$ 

20 

$ 

SECURITY 







UNIX Security II 

Aug. '90 

13 

16 

$ 

_ 8 

$ 

UNIX Security 

Aug. '88 

7 

7 

$ 

5 

$ 

MACH 







Mach Symposium 

Nov. '91 

24 

28 

$ 

_ 14 

$ 

Mach Workshop 

Oct.'90 

17 

20 

$ 

9 

$ 


Continued - see reverse 
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Qty Proceedings 

Member 

Price 

Non-Member * 
Price 

Subtotal 

Foreign 

Postage 

Total 

DISTRIBUTED & MULTIPROCESSOR SYSTEMS (SEDMS) 






SEDMS II 

Mar. '91 

30 

36 

$ 

20 

$ 

SEDMS 

Oct. '89 

30 

30 

$ 

20 

$ 

GRAPHICS 







Graphics Workshop V 

Nov. '89 

18 

18 

$ 

10 

$ 

_Graphics IV 

_Graphics III 

Graphics II 

Oct. '87 

10 

10 

$ 

10 

$ 

Nov.’86 

10 

10 

$ 

5 

$ 

Dec. '85 

7 

7 

$ 

5 


OTHER WORKSHOPS 







_UNIX Transaction Processing 

May *89 

Apr. '89 
Sept. '88 

12 

12 

$ 

8 

$ 

_ Software Management 

20 

20 

£ 

15 

$ 

_UNIX & Supercomputers 

20 

20 

$ 

10 

$ 







Discounts are available for bulk orders. Please inquire . Total price of Proceedings 

Calif, residents add sales tax 
Total foreign postage 
Total enclosed 


PAYMENT OPTIONS* 

_Check enclosed- payable to USENIX Association 

_Charge my: _ VISA I BS !_ MC Account# _ _Exp.Date_ 

_ Purchase order enclosed Signature 

* Outside the USA? Please make your payment in US currency by one of the following: 

- Check - issued by a local branch of a US Bank 

- Charge (VISA, MasterCard, or foreign equivalent) 

- International postal money order 

Shipping Information Ship to: _ 

Please allow 2-3 weeks for delivery. Overseas orders ._ 

are shipped via air printed matter. 

Please mail or fax this order form to address below. 

• If you are not a member and wish to receive our membership information packet, please check this box. □ 

2560 Ninth Street • Suite 215 • Berkeley, CA • 94710 • Tel 510/528-8649 • FAX 510/548-5738 • office@usenix.org 
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SUBSCRi PTIOJM ORDER FORM 


PROCEEDINGS 

Please enter my one-year subscription* to the 1992 USENIX Conference, Workshop and Symposia 
Proceedings, which include: 

San Francisco Technical Conference - January 1992 

Symposium on Experiences with Distributed & Multiprocessor Systems (SEDMS) III - March 1992 

Workshop on Micro-Kernels and other Kernel Architectures - April 1992 

File Systems Workshop - May 1992 

San Antonio Technical Conference - June 1992 

C++ Conference - August 1992 

UNIX Security III Symposium - September 1992 

Systems Administration (LISA) VI Conference - October 1992 


COST: USENIX members: $170.00 Non-members: $214.00 
California residents add applicable sales tax. 

Outside U.S.A. and Canada? Add $30.00 for surface postage. 
Total amount enclosed $. 


*KOTE: Corporate, Educational and Supporting Members of USENIX automatically receive a subscription 
to all proceedings published during their term of membership, which may overlap with this offer. 


PAYMENT OPTIONS 


I | Check enclosed payable to USENIX Association. 
Please charge my: Visa Q MasterCard 


] Purchase order enclosed. 



Account # 


Exp. Date 


Signature 


Outside the U.S.A.? Please make your payment in U.S. currency by one of the following: 

* Check - issued by a local branch of a U.S. Bank 

* Charge (Visa, MasterCard, or foreign equivalent) 

* International postal money order 


1/92 


Name___ 

Address ____ 

City ______State/Country_Zip/Postal Code 


Please mail this order form to: USENIX Association 

2560 Ninth Street 
Suite 215 

Berkeley, CA 94710 

The proceedings are shipped within one week of publication. 


This offer is good through 
December 31,1992 


2560 Ninth Street • Suite 215 • Berkeley, CA • 94710 • 510/528-8649 • FAX 510/548-5738 • office@usenix.org 
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Local User Groups 

The Association will support local user groups by doing a mailing to assist the formation of a new 
group and publishing information on local groups in ;login:. At least one member of the group must 
be a current member of the Association. Send additions and corrections to login@usenix.org. 


CA - Fresno: the Central California UNIX Users 
Group consists of a uucp -based electronic mailing 
list to which members may post questions or in¬ 
formation. For connection information: 

Educational and governmental institutions: 
Brent Auernheimer (209) 278-4636 

brent@CSUFresno.edu or csufreslbrent 

Commercial institutions or individuals: 

Gordon Crumal (209) 251-2648 

csufreslgordon 


CA - Irvine: the UNIX Users Association of 
Southern California meets the 2 nd Monday of 
each month. 

Paul Muldoon (714) 556-1220 

Horizons ext. 137 

Santa Ana, CA 92705 


CO - Boulder: the Front Range UNIX Users 
Group meets monthly at different sites. For meet¬ 
ing schedule, send email to fruug-info@fruug.org 

Steve Gaede gaede@fruug. org 

Software Design (303) 444-9100 

& Analysis, Inc. 

1113 Spruce St., Ste. 500 
Boulder, CO 80302 


FL - Coral Springs: 

S. Shaw McQuinn (305) 344-8686 

8557 W. Sample Road 
Coral Springs, FL 33065 


FL - Fort Lauderdale/Miami: The South Florida 
UNIX Users Group meets the 2 nd Tuesday of each 
month. 

Tony Vincent, John McLaughlin (305) 776-7770 
{sun ,novavax ,gould}! sun vice! tony 
jmclaughlin@sun.com 

John O’Brien (305) 475-7633 

gatech! uflorida! no va vax! j ohn 


FL - Western: The Florida West Coast UNIX 
Users Groups meeting the first Thursday of every 
month. 


Richard Martino 
Tony Becker 
mcrsysltony 

Ed Gallizzi, Ph.D. 
e. galizzi@compmail. com 

Jay Ts 

uunet! pdn! tscs Imetran! j ay 

Dave Lewis 
dhl@ccd. harris. com 


FL - Orlando: the Central Florida UNIX Users 
Group meets the 3 rd Thursday of each month. 

Mike Geldner (407) 862-0949 

codas!sunfla!mike 

Ben Goldfarb (407) 275-2790 

goldf arb@hcx9. ucf. edu 

Mikel Manitius (407) 869-2462 

{codas, attmail}! mikel 


GA - Atlanta: meets on the 1 st Monday of each 
month in White Hall, Emory University. 

Atlanta UNIX Users Group 
P.O. Box 12241 
Atlanta, GA 30355-2241 

Mark Landry (404) 365-8108 


MI - Detroit/Ann Arbor: The SouthEastern Mich¬ 
igan Sun Local Users Group meets jointly with 
the Nameless UNIX Group on the 2 nd Thursday of 
each month in Ann Arbor. 

Steve Simmons home: (313) 426-8981 

scs@lokkur.dexter.mi.us office: (313) 769-4086 

K. Richard McGill Bill Bulley 

rich@sendai.ann-arbor.mi.us web@applga.uucp 


MN - Minneapolis/St. Paul: meets the 1 st Wednes¬ 
day of each month. 

UNIX Users of Minnesota Robert A. Monio 
17130 Jordan Court pnessutt@dmshq.mn.org 
Lakeville, MN 55044 (612) 220-2427 


(813) 536-1776 
(813) 799-1836 

(813) 864-8272 

(813) 979-9169 

(407) 242-4372 
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MO - St. Louis: 

St. Louis UNIX Users Group Terry Linhardt 
P.O. Box 2182 uunetljgaltstllterry 

St. Louis, MO 63158 (314) 772-4762 


NE - Omaha: meets monthly, 
/usr/group/nebraska Phillip Allendorfer 

P.O. Box 31012 

Omaha, NE 68132 (402) 423-1400 


New England - Northern: meets monthly at dif¬ 
ferent sites. 

Peter Schmitt 

Peter.Schmitt@dartvax!dartmouth.edu 

Kiewit Computation Center (603) 646-2085 
Dartmouth College 
Hanover, NH 03755 


NJ - Princeton: the Princeton UNIX Users Group 
meets monthly. 

Peter J. Holsberg mccclpjh 

Mercer County (609) 586-480(1 

Community College 
1200 Old Trenton Road 
Trenton, NJ 08690 


NY - New York City: Unigroup of New York City 
meets every other month in Manhattan. 

Unigroup of New York City 
G.P.O. Box 1931 
New York, NY 10116 

Peter Gutmann (212) 618-0973 

peterg@murphy.com 


OK - Tulsa: the Tulsa UNIX Users Group, $usr, 
meets the 2 nd Wednesday of each month. 

Stan Mason (918) 560-5329 

tulsix! smason@drd. com 

Mark Lawrence (918) 743-3013 

mark@drd.com 


TX - Austin: CACTUS meets the 3 rd Thursday of 
each month. 

Capital Area Central Texas UNIX Society 
P.O. Box 9786 
Austin, TX 78766-9786 
officers@cactus. org 

James Johnson (512) 331-3781 

president@cactus. org 


TX - Dallas/Fort Worth: 

Dallas/Fort Worth UNIX Users Group 
660 Preston Forest, Suite 177 
Dallas, TX 75230 

Kevin Coyle (214) 991-5512 

kevinc@shared. com 


TX - Houston: the Houston UNIX Users Group 
(Hounix) meets the 3 rd Tuesday of each month. 

Hounix answering machine (713) 684-6590 

Bob Marcum, president (713) 270-8124 

Chuck Bentley, vice-president (713) 789-8928 

chuckb@hounix. uucp 


WA - Seattle: meets monthly. 

Bill Campbell (206) 947-5591 

Seattle UNIX Group Membership Information 
6641 East Mercer 
Mercer Island, WA 98040-0820 
bill@celestial. com 


Washington, D.C.: meets the 1 st Tuesday of each 
month. 

Washington Area UNIX Users Group 
9811 Mallard Drive 
Laurel, MD 20708 

Alan Fedder (301) 953-3626 


CANADA - Toronto: 

Evan Leibovitch (416) 452-0504 

143 Baronwood Court evan@telly.on.ca 

Brampton, Ont. Canada L6V 3H8 
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USENIX Association 
2560 Ninth Street, Suite 215 
Berkeley, CA 94710 


SECOND CLASS 
APPLICATION PENDING 
at Berkeley, CA and 
addititional offices 


Postmaster: Send address changes to USENIX Association, 2560 Ninth Street, Ste. 215, Berkeley, CA 94710 . 


Calls for Papers 
Book Reviews 
Report from EurOpen 




